X10 Community Forum
💬General Category => Mac/Linux & Open Source and the X10 Home => Raspberry Pi, Arduino & other SBC => Topic started by: mike on October 17, 2018, 06:32:50 PM
-
In the last 3 weeks I have learned something significant about raspbian stretch operating system: THE LITE AND THE LARGER FULL GUI SYSTEMS WILL NOT RUN THE SAME PROGRAMS!
I spent approx. 100 hours over the last 2 weeks trying to get various various python3 helper programs to load so my Domoticz HA program could use them. Programs that load via:
sudo apt-get install python3-pip
sudo pip3 install Crypto
sudo pip3 install broadlink
sudo pip3 install pyaes
sudo cp -r /usr/local/lib/python3.5/dist-packages/Crypto/ /usr/lib/python3.5/
sudo cp -r /usr/local/lib/python3.5/dist-packages/broadlink /usr/lib/python3.5/
NONE would load on my various full stretch with GUI images. ALL failed on openSSL errors among others. I COULD get them to load if I updated from python3.5 to 3.6 or 3.7, but then the new python would not react well with the old still required python3.5. So no go.
I had the idea to try a stretch LITE image... BINGO - EVERYTHING LOADS AND SO FAR WORKS.
I wanted to share this huge find; if you cannot get a pi with full stretch to load programs properly, try the LITE version.
-
The full GUI version (Raspbian) include python, java and a few other programing languages these are not always the version required. ::) :' the lite version is lite and includes none of these so they must be loaded.
This is one reason I stayed away from some software when trying to find the best fit for a newbie and PI with Linux.
-
actually the LITE includes python 3.5 so I did not need to load it.
-
actually the LITE includes python 3.5 so I did not need to load it.
Mike the Lite version of any Linux version is exactly that. A stripped down version of the OS and the bare essentials to get your Pi booting to the CLI.
It allows you to select particular packages like Python to install from scratch with all it's relevant dependencies. So many other packages rely on Python to operate and particular versions you will find have a release candidate tied to them. The Desktop version of Raspbian will have many Python reliant packages installed.
To get the latest version of Python from the Raspbian repositories the sudo apt-get update and the sudo apt-get upgrade will achieve this. Bear in mind that the Debian repositories (the repositories where most of the Raspbian packages are extracted from) are usually a number of versions behind.
In order to acquire a later version you need to step outside of the Aptitude package manager and compile and install the latest version from a GitHub. Once you begin doing this you need to know what you are doing as this method will not know or check that you already have an earlier version installed. If a later version of a package is installed on top of an earlier version it usually ends up in a broken OS.
I have mentioned it here many times to go with Raspbian Lite and now you have discovered why. Nothing magic really. Installing Raspbian Lite allows you to construct and tailor your own Raspbian distribution particularly when it comes to using your distribution as a server, as in Domoticz or HomeGenie.
You should never need to use a GUI on a server as all maintenance should be carried out remotely once the initial installation has been completed. Using the Raspbian Lite version alllows you to construct a dedicated server with only the essential packages that relate to that server's operability. Nothing more, nothing less.
Packages that require SSL authentication to install can be resolved by installing the relevant SSL certificates on your system. Whether you use the Lite or the Desktop version is not relevant here.
If you want to tie your system to a particular release of a package it's just a case of issuing a particular command to make the Aptitude manager aware of this.
-
Perhaps the pi gods just do not want me to join their membership group!
So I am almost finished making this 8gb card the way I want it and do a last SSH install (pyaes) and it complains... OK, maybe need a reboot first. reboot. it is gone.
this morning come in and see all kinds of crashes - mostly something called something dev... won't get to sign in line, no wifi. can't get to where I can try to recover. Oh well. What is another 20 hours of trying to build a raspbianpi card?
So last week I buy 10pc 8gb cards on ebay as I only had 1 left each 8 & 16gb. I certainly do not want to be waiting on 2Mb/s writes onto a 16gb card anymore!
So image a new LITE onto 8gb card (5.0Mb/sec), relatively fast. Will start anew this morning... I know I should make back up image on way thru - just another 1/2 hour each time taker... At least I now know that a LITE is required to get python programs to load without errors into -V 3.5!
-
Perhaps the pi gods just do not want me to join their membership group!
So I am almost finished making this 8gb card the way I want it and do a last SSH install (pyaes) and it complains... OK, maybe need a reboot first. reboot. it is gone.
this morning come in and see all kinds of crashes - mostly something called something dev... won't get to sign in line, no wifi. can't get to where I can try to recover. Oh well. What is another 20 hours of trying to build a raspbianpi card?
So last week I buy 10pc 8gb cards on ebay as I only had 1 left each 8 & 16gb. I certainly do not want to be waiting on 2Mb/s writes onto a 16gb card anymore!
So image a new LITE onto 8gb card (5.0Mb/sec), relatively fast. Will start anew this morning... I know I should make back up image on way thru - just another 1/2 hour each time taker... At least I now know that a LITE is required to get python programs to load without errors into -V 3.5!
Mike both the LIte and the Desktop feed off the same repository so they will both give you the latest version of a particular package if you require it. If you find there is a package version you do not need just use the remove or purge commands prior to installing the one you do.
Python as you have now learned is quite specific on its version numbering when installing. As I said before once you step outside the Aptitude installer you're pretty much at the mercy of compilers.
-
So reality is many python helper programs will NOT install on raspbian FULL GUI operating system, yet install just fine on raspbian LITE. Although I agree BOTH versions are based on the same code, reality is reality, and ONLY the LITE version allows the various python programs I required for integrating both X10 (mochad) & Broadlink (broadlink, pyaes, cypro) to install.
THIS time, having 8gb cards instead of 16gb, and buying more (all class 4 - remember that was the fastest version back ini 8gb days), I was able to make backup images as I added each program, at the rate of 19MB/s so 6 minute writes, 1.5 minute confirms. I will post a link my fully installed domoticz running system once finished tweaking.
I am still learning how to use the built in, integrated into domoticz, learn and save function functions of broadlink, and my mochad is not being 100% for some reason - it appears my cm15 is still behind an x10 powerline filter. Learn RF button pushes seem to build switches 100% of the time, but then the switch does not turn lite on/off but 20% of the time. I know it can work because I DID have it working 100% solid in a past install.
I need to thank both Tuiceman and petera for all your patience and help along this journey. I continue to learn little linux commands each day. Latest was CHOWN as broadlink installed a folder to hold its learned codes as root owned so I could not look into it easily.
-
I dont think I was of any helpto you on this endeavor mike.
You stuck with this when many would have thrown in the towel.(me included)
I'll give Domonticz more of a go after hunting season as I'll have more time then. I look forward to your link as I'm sure it will be helpful to many users looking at a x10 pi setup.
-
So reality is many python helper programs will NOT install on raspbian FULL GUI operating system, yet install just fine on raspbian LITE. Although I agree BOTH versions are based on the same code, reality is reality, and ONLY the LITE version allows the various python programs I required for integrating both X10 (mochad) & Broadlink (broadlink, pyaes, cypro) to install.
THIS time, having 8gb cards instead of 16gb, and buying more (all class 4 - remember that was the fastest version back ini 8gb days), I was able to make backup images as I added each program, at the rate of 19MB/s so 6 minute writes, 1.5 minute confirms. I will post a link my fully installed domoticz running system once finished tweaking.
I am still learning how to use the built in, integrated into domoticz, learn and save function functions of broadlink, and my mochad is not being 100% for some reason - it appears my cm15 is still behind an x10 powerline filter. Learn RF button pushes seem to build switches 100% of the time, but then the switch does not turn lite on/off but 20% of the time. I know it can work because I DID have it working 100% solid in a past install.
I need to thank both Tuiceman and petera for all your patience and help along this journey. I continue to learn little linux commands each day. Latest was CHOWN as broadlink installed a folder to hold its learned codes as root owned so I could not look into it easily.
Mike, generally program authors distribute their work via what is known as a package installer. Take for instance, HomeGenie which has been discussed at length here. The package installer used in this case is Gdebi.
Gdebi will assemble all the component parts (dependencies) of a particular program and will check to see if your system already has any of those required components already installed. If not it will install them before it installs the main body of the program.
If you are using a Lite version of the OS it will probably need to install more component parts but the main thing is it will install what is needed for their program to run on your system. The fact that you are running the Lite or Desktop version of the OS is not an underlying factor here.
You can come across a program, usually from a GitHub that will not include the facility of a package manager. The author usually points out that you need to install other component parts prior to manually installing their program.
The final scenario you are likely to encounter is a program on a GitHub which is source code that needs to be compiled and built prior to installation. This is a fairly technical method and the author makes assumptions that you are very familiar with the Linux OS. You will have worked out yourself what component parts are required to compile these programs yourself.
PIP, another package installer which you are now familiar with, allows you to install a Python designed program onto your your system. This program and it's dependencies (in your case Domoticz) will be tied to a particular version of Python at the time of installation and should receive regular updates from the author. Not in all cases though as you've experienced with the Broadlink module. That's when you experience difficulties as different program modules are demanding different versions of Python.
I found this to be an interesting read on the subject https://www.datacamp.com/community/tutorials/pip-python-package-manager
-
So I had broadlink working, it would learn IR & non X10 codes,, then repeat them back from the switch I made for them. Then sometime yesterday it stopped working, would not go into learn mode (orange light on), and would not send code when switch pushed. hmmm... oh well, par for my course.
I re imaged a card with the working version from the day before, still did not fix broadlink...
meanwhile, mochad stopped working. Had it at 100% working, loaded all my x10 devices into dommoticz, including a couple ds10 door security switches and keyfob kr10 arm/disarm. kr10 would not send to arm my security, but I did not expect it to - that is what broadlink was for. But all working. ds10 shows cute locked padlock when closed, red siren when open...
remade image complete minus mochad, reinstalled mochad and it worked fine again - all morning. then stopped working again.
ps -A shows mochad still running. echo "pl a3 on" | nc -w1 localhost 1099 sends but does not report back working. ./mochad reports it cannot find a cm15.
I just wonder how others are getting these pi's to run consistently for any length of time...
-
So I had broadlink working, it would learn IR & non X10 codes,, then repeat them back from the switch I made for them. Then sometime yesterday it stopped working, would not go into learn mode (orange light on), and would not send code when switch pushed. hmmm... oh well, par for my course.
I re imaged a card with the working version from the day before, still did not fix broadlink...
meanwhile, mochad stopped working. Had it at 100% working, loaded all my x10 devices into dommoticz, including a couple ds10 door security switches and keyfob kr10 arm/disarm. kr10 would not send to arm my security, but I did not expect it to - that is what broadlink was for. But all working. ds10 shows cute locked padlock when closed, red siren when open...
remade image complete minus mochad, reinstalled mochad and it worked fine again - all morning. then stopped working again.
ps -A shows mochad still running. echo "pl a3 on" | nc -w1 localhost 1099 sends but does not report back working. ./mochad reports it cannot find a cm15.
I just wonder how others are getting these pi's to run consistently for any length of time...
What version of Mochad are you using. Sounds like your version of the daemon is locking up and disconnecting. You could try version 0.1.18 found here https://github.com/linuxha/.
Mochad 0.1.17 on my Pi is running fine at all times.
-
There is also another possibility as to why an installer works on lite but not the GUI install. In some cases, a program is compatible with one version of a dependency but not the newest variant. An example of this is HG which works with older versions of Mono but not the latest version (not sure if that's still the case, it's been a while since last install). As a result, if you installed a newer version of Raspbian, HG would install but not function correctly. Going back to an older version worked.
It's possible that the Lite version didn't have a dependency installed so the installer took care of it. The GUI version had a newer version of the dependency and so the installer didn't touch it. The newer version wouldn't work with the app and things were broken. This may be correctable by removing that dependency and installing an older version, but it could affect other things...a bit of a quagmire!
-
An example of this is HG which works with older versions of Mono but not the latest version (not sure if that's still the case, it's been a while since last install).
the latest stable version of HG I believe works with the latest mono but I believe petera discovered it now need the newer mono for some of the User created addon programs. so it appears HG latest beta versions at least now require the new mono.
-
I just wonder how others are getting these pi's to run consistently for any length of time...
My Pis have been running just fine under HG.
I tryed Domonticz On another SB as I didn't wish to put my HA setup out of commission while playing with Domonticz.
That was a good desission as I couldn't keep Domoticz running longenough to do a good assessment.
As petera suggested if everything else seems to be running on the Pi try another version of Mochad.
If that still doesn't help move on to another Software. ( maybe something easier to setup)
-
Petera, mochad 1.16 did not work well so I reimaged fresh and installed 1.17 - it ran for a day before stopping. I am sure it is mochad code issue... Here are two commands that pretty much show me the program is screwed up:
pi@raspberrypi:~/mochad-0.1.17 $ ./mochad
Message from syslogd@raspberrypi at Oct 21 19:49:49 ...
mochad[565]: libusb_open_device_with_vid_pid failed
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-21 19:49:49 UTC):
mochad[565]: libusb_open_device_with_vid_pid failed
Message from syslogd@raspberrypi at Oct 21 19:49:49 ...
mochad[565]: Could not find/open CM15A/CM19A -5
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-21 19:49:49 UTC):
mochad[565]: Could not find/open CM15A/CM19A -5
CANNOT FIND THE CM15.... BUT BUT BUT:
Can't locate it right now, but found another status line command where it interogated mochad - and it very clearly stated "CM15 FOUND."
I could run both commands right after each othere and consistency. one says cm15 found, other says cm15 not found...
anyway, I recall rumors of a 1.18 ver of mochad but never could find it - I will try that! Thanks!
-
Petera, mochad 1.16 did not work well so I reimaged fresh and installed 1.17 - it ran for a day before stopping. I am sure it is mochad code issue... Here are two commands that pretty much show me the program is screwed up:
pi@raspberrypi:~/mochad-0.1.17 $ ./mochad
Message from syslogd@raspberrypi at Oct 21 19:49:49 ...
mochad[565]: libusb_open_device_with_vid_pid failed
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-21 19:49:49 UTC):
mochad[565]: libusb_open_device_with_vid_pid failed
Message from syslogd@raspberrypi at Oct 21 19:49:49 ...
mochad[565]: Could not find/open CM15A/CM19A -5
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-21 19:49:49 UTC):
mochad[565]: Could not find/open CM15A/CM19A -5
CANNOT FIND THE CM15.... BUT BUT BUT:
Can't locate it right now, but found another status line command where it interogated mochad - and it very clearly stated "CM15 FOUND."
I could run both commands right after each othere and consistency. one says cm15 found, other says cm15 not found...
anyway, I recall rumors of a 1.18 ver of mochad but never could find it - I will try that! Thanks!
Did you try this http://www.domoticz.com/forum/viewtopic.php?f=56&t=21246&p=180247&hilit=mochad#p180247
-
tnx for timer -w1 post; yes, I have that under control; if not used, sending a command leaves mochad OPEN and ANY and ALL x10 commands sent or received are seen real time - useful feature! then that window needs to be close by ^x... but with -w1 timer sent, it times out and only the command just sent happens and its report back given, then we are returned to pi command line.
I will try the 1.18 you found tonight in front of tv...
tnx
-
What version of Mochad are you using. Sounds like your version of the daemon is locking up and disconnecting. You could try version 0.1.18 found here https://github.com/linuxha/.
Mochad 0.1.17 on my Pi is running fine at all times.
I cannot find mochad 1.18 at the site shown?
-
What version of Mochad are you using. Sounds like your version of the daemon is locking up and disconnecting. You could try version 0.1.18 found here https://github.com/linuxha/.
Mochad 0.1.17 on my Pi is running fine at all times.
I cannot find mochad 1.18 at the site shown?
0.1.17 should work anyway. Just try Moched on a separate SD card with nothing else running.
-
I've posted this before but here it is again...........
NOTE Hansbit on May 10 2018: There is an issue with Mocad 0.1.17 and Debian Stretch that causes nc to become unresponsive after a first command. The solution is to add a time out parameter (-w1) to you nc command. Example:
echo "pl a1 on" | nc -w1 localhost 1099
Note (assuming your installation is on a Raspberry):
The file 'readme.txt' in '/home/pi/domoticz/scripts' say : 'to use this script, remove the underscore in front of the filename' , so go in the directory and rename the file
cd /home/pi/domoticz/scripts
mv _domoticz_main domoticz_main
Make sure the script has executable rights with:
chmod +x domoticz_main
To use this script you need the latest version (minimum Vs. 1.0.940) to make light buttons in the GUI !
The option 'dim' and 'bright' is still in test !!
You can add the 'Dummy' hardware device, and add manual light/switches
If 0.1.17 is still giving problems go to 0.1.16 and try that
-
I know about -w1 to terminate the command; the other part about the script is for when you add ocahd command lines to domoticz main script I believe. Otherwise that section is meaningless. i went ahead and copied it from _dom... to dom and rebooted and of course no change. Mochad 1.17 is not seeing the cm115 properly... I may try 1.16 again since there does not see to be a 1.18 in existence...
-
"Works very well. HOWEVER, In ActiveHomePro, you must clear the CM15A interface memory, then set the CM15A to NOT transceive RF to PL signals (per the instructions). If you skip this step, Mochad may lockup on you."
I DID turn on transceive in recent test... about same time it started locking up... hmmm... I will try turning that off before hosing this version of image... cant get to it until tomorrow mid morning tho...
-
here is the other command showing how mochad is confused over cm15:
pi@raspberrypi:~/mochad-0.1.17 $ sudo systemctl status mochad
● mochad.service - Start mochad service
Loaded: loaded (/lib/systemd/system/mochad.service; disabled; vendor preset:
Active: active (running) since Mon 2018-10-22 21:56:18 UTC; 20min ago
Process: 273 ExecStart=/usr/local/bin/mochad (code=exited, status=0/SUCCESS)
Main PID: 276 (mochad)
CGroup: /system.slice/mochad.service
└─276 /usr/local/bin/mochad
Oct 22 21:56:18 raspberrypi systemd[1]: Starting Start mochad service...
Oct 22 21:56:18 raspberrypi systemd[1]: Started Start mochad service.
Oct 22 21:56:18 raspberrypi mochad[276]: Found CM15A
Oct 22 21:56:18 raspberrypi mochad[276]: In endpoint 0x81, Out endpoint 0x02
[2]+ Stopped sudo systemctl status mochad
pi@raspberrypi:~/mochad-0.1.17 $ ./mochad
pi@raspberrypi:~/mochad-0.1.17 $
Message from syslogd@raspberrypi at Oct 22 22:17:28 ...
mochad[664]: libusb_open_device_with_vid_pid failed
Broadcast message from systemd-journald@raspberrypi (Mon 2018-10-22 22:17:28 UTC):
mochad[664]: libusb_open_device_with_vid_pid failed
Message from syslogd@raspberrypi at Oct 22 22:17:28 ...
mochad[664]: Could not find/open CM15A/CM19A -5
Broadcast message from systemd-journald@raspberrypi (Mon 2018-10-22 22:17:28 UTC):
mochad[664]: Could not find/open CM15A/CM19A -5
-
Mike not sure of the contents of your Systemd service file but try this one for Mochad. Just change the locations to suit your setup
[Unit]
Description=mochad is a Linux TCP gateway daemon for X10 CM15A/CM15PRO/CM19A
After=sysinit.target
[Service]
Type=forking
ExecStart=/usr/local/bin/mochad
Restart=on-failure
[Install]
WantedBy=multi-user.target
Use Mochad v 0.1.16 with this
-
tnx. would that have any affect with my version 1.17? my understanding it uses u-dev instead of systemd?
And don't these just get it started then not used anymore? I am guessing here... but m y mochad is always running as proved by various ps -A and system check commands.... it just seems to loose contact with the cm15...?
-
tnx. would that have any affect with my version 1.17? my understanding it uses u-dev instead of systemd?
And don't these just get it started then not used anymore? I am guessing here... but m y mochad is always running as proved by various ps -A and system check commands.... it just seems to loose contact with the cm15...?
Have a read of this post. mmauka is a member here and encountered similar difficulties to yourself so did a bit of work on Mochad.
http://forums.x10.com/index.php?topic=22045.30
The UDEV rule is created automatically as soon as you make Mochad from the GitHub. You then create the Systemd service to launch Mochad as a daemon that runs in the background and launches as soon as its called on.
A pure service will only run for a specified amount of time and end. A daemon on the other hand will remain available to the system when it's required https://www.makeuseof.com/tag/control-linux-start-services-daemons/
-
wow. lots to learn! tnx. I have seen some of mmauka's posts; IIRC he is one that made the 1.18 version, but all it did was add ipv6 so not going to help my issues.
I still need to turn off transceive in cm15 and see if that is whhat is causing it to dissappear...
-
So I used windows AHP and shut off transceive house codes and now Domoticz is sending code thru mochad 1.17 again to turn lites on and off... good so far.
In the last days I saw posts saying I should rename unused _domoticz_main to domoticz_main to make mochad work... no clue, but I did it... here is that file:
------------------------------------
#!/bin/sh
startup_path=$1
hardware_id=$2
device_id=$3
status=$4
status2=$5
devname=$6
echo "startup_path=${startup_path}, hardware_id=${hardware_id}, device_id=${device_id}, status=${status}, status2=${status2}, devname=${devname}"
---------------------------------------------
and here is the result in the domoticz log:
----------------------
2018-10-23 15:45:42.859 Error: (Broadlink-RM2) Error Connecting to Broadlink device....192.168.0.3
2018-10-23 15:46:12.371 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:46:12.389 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:46:12.389 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:46:42.380 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:46:42.420 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:46:42.420 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:47:12.387 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:47:12.396 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:47:12.397 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:47:28.611 (Mochad) Lighting 1 (Workshop, B5)
2018-10-23 15:47:28.634 (Mochad) Lighting 1 (Workshop, B5)
2018-10-23 15:47:29.669 (Mochad) Lighting 1 (Workshop, B5)
2018-10-23 15:47:29.607 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:47:29.705 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:47:30.663 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:47:33.075 (Mochad) Lighting 1 (B10, Ele Wrkshop music-lite)
2018-10-23 15:47:33.098 (Mochad) Lighting 1 (B10, Ele Wrkshop music-lite)
2018-10-23 15:47:34.069 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:47:34.145 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:47:42.395 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:47:42.430 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:47:42.430 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:48:12.403 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:48:12.408 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:48:12.408 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:48:28.129 (Mochad) Lighting 1 (B10, Ele Wrkshop music-lite)
2018-10-23 15:48:28.152 (Mochad) Lighting 1 (B10, Ele Wrkshop music-lite)
2018-10-23 15:48:29.118 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:48:29.195 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:48:42.412 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:48:42.441 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
2018-10-23 15:48:42.442 (Broadlink-RM2) Calling message handler 'onHeartbeat'.
2018-10-23 15:48:45.733 (Mochad) Lighting 1 (Workshop, B5)
2018-10-23 15:48:46.725 Status: Executing script: /home/pi/domoticz/scripts/domoticz_main
2018-10-23 15:49:12.420 (Broadlink-RM2) Pushing 'onHeartbeatCallback' on to queue
2018-10-23 15:49:12.421 (Broadlink-RM2) Processing 'onHeartbeatCallback' message
201
-------------------------------------
Ignoring the broken broadlink above, I see that renamed file is running everytime mochad does something! I may delete it (I have the _domoticz_main still there) to see if it does anything...
I am not too worried about the double and triple hits as I have so many repeaters and my main cm15 still active here...
-
Clearing timers/macros and turning off transceiver and house code monitoring was mentioned way back. In fact it's mentioned in the instructions when doing the Makefile in Mochad.
I assumed you had already carried that out.
-
ya, I know. I have seen it all along. I just have issues with doing things that make no sense - like turning off trancieved codes. It worked - for 1/2 a day. working 100% b4 lunch, then I left to go bushhog some of 80 acres across the street; back and mochad is running, and still responds to such as echo "pl a1 on" | nc localhost 1099, but domoticz not working...
sheesh... I used to think windows are AWFUL and unreliable, but after messing with pi I have new respect for it!
-
Can you confirm that Mochad is running uninterrupted now. If this is the case you now need to add a delay to your Domoticz Systemd service file to ensure that Mochad is up and running before the Domoticz server. Domoticz would start fairly quick and would miss the Mochad daemon service.
Something alomg these lines https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd
-
So my last issue was mochad loosing communications with the cm15 due to having transceiver turned on - pretty weird...
All that time of not working, mochad WAS running in the background _ i could see it on the running list with ps -A and ps aux commands. So no timer issue. I am in process of searching whole SD card for file named systemd but have yet to find it. It would be interesting to see what is in it.
Mochad has been rock solid now all day and domoticz is interfacing solid with it also. My issue must have been that transceive turned on or that file that is running every time mochad gives domoticz a command (_domoticz_main). I have not deleted it yet to verify that it has no affect. Will do, but enjoying it working for now...
Since it was working, I addressed the built in broadlink RM issue; turns out I had wrong IP address set (0.3 instead of 0.2) ... When it first worked I had used domoticz's automatic find the RM module and just copy pasted the IP and MAC address; later, in screwing with it I deleted it and redid it and punched in wrong IP. So it is communicating now too with domoticz. I do not know if it actually works (learn code then spit it back out as a switch icon) because I must be net to it in workshop to teach it... Tomorrow is another day!
Assuming that works, I will change my pi pw back to raspberry and make an 8gb image and make it available on line.
-
So my last issue was mochad loosing communications with the cm15 due to having transceiver turned on - pretty weird...
All that time of not working, mochad WAS running in the background _ i could see it on the running list with ps -A and ps aux commands. So no timer issue. I am in process of searching whole SD card for file named systemd but have yet to find it. It would be interesting to see what is in it.
Mochad has been rock solid now all day and domoticz is interfacing solid with it also. My issue must have been that transceive turned on or that file that is running every time mochad gives domoticz a command (_domoticz_main). I have not deleted it yet to verify that it has no affect. Will do, but enjoying it working for now...
Since it was working, I addressed the built in broadlink RM issue; turns out I had wrong IP address set (0.3 instead of 0.2) ... When it first worked I had used domoticz's automatic find the RM module and just copy pasted the IP and MAC address; later, in screwing with it I deleted it and redid it and punched in wrong IP. So it is communicating now too with domoticz. I do not know if it actually works (learn code then spit it back out as a switch icon) because I must be net to it in workshop to teach it... Tomorrow is another day!
Assuming that works, I will change my pi pw back to raspberry and make an 8gb image and make it available on line.
Mike Systemd is the name of the service that launches the application. If it was Mochad than the Systemd service would be called something like mochad.service or if it was Domoticz it would be called domoticz.service. Generally these would be files you would create yourself to launch on system boot and they would run unattended on your system.
Read up on Systemd to get an understanding on how this works. These files are usually stored in the folder /etc/systemd/system.
Gotta sign off for a while now. Back to the day job as they say :)
-
Nice job and glad you made it work. Thanks for sharing everything.
-
tnx brobin, not out of the woods all the way yet... broadlink plugin seems to only work for IR at this point and not RF. So it will not learn X10 codes - yet.
I see on forums one other person found this to be true also...
First try with broadlink android app likewise does IR but not RF...
-
tnx brobin, not out of the woods all the way yet... broadlink plugin seems to only work for IR at this point and not RF. So it will not learn X10 codes - yet.
I see on forums one other person found this to be true also...
First try with broadlink android app likewise does IR but not RF...
I'm not at all familiar with the plugin so this is just a thought
It is possible the plugin was only coded to learn IR like for the tiny BlackBean.
If you manually add a RF code will it send it?
If you still have HA-Bridge setup on your Windows PC you can copy the RF code for the device you wish the plugin to send.
-
RIGHT ON TUICEMEN! You are so right!
The python3 code called broadlink ONLY does IR learning since the author did not / does not have any RF stuff to test it - so his RF code does not work! A few others have modified versions that work for some people. Matt seems willing to make his official version work, so I offered to buy him a Broadlink RM Pro+ and send him an x10 keyfob to test with! Will see if he takes me up on it!
I will also be trying some of these other versions today if I get time.
I have learned that the broadlink has TWO steps to learn RF codes - interesting stuff! Since iit can learn and emulate both 432mhz and 310mhz signals, it learns by FIRST doing a frequency SWEEP to find rf signals... Once found, it then goes into SECOND step and records the digital code riding on that RF signal. Pretty cool. There is a new(er?) android app called 'Broadlink Hub" that automatically scans network and finds the broadlink device, then has simple buttons to learn IR and separate one called 'freq sweep' - now I know the meaning of that! - to find and learn RF. Unfortunately it does not find any of my X10 stuff.
Meanwhile I do have my security codes from your help with the habridge, and yes, I think I can decode how to implement it into a new ini file to load into this system.
Also, Matt did build a small webserver, generator of modified e-control files and import into domoticz; unfortunately I am not smart enough yet to make it work - but I am getting there!
And last, I reinstalled e-control on my android phone and will today sometime try to learn X10 codes anew, in anticipation of learning how to use the broadlink automatic built in import function.
-
Hey Tuicemen, you ever have an issue where your broadlink changes IP addresses? Mine seems to be bouncing from 192.168.0.3 (normal) to 192.168.0.2... and back. It changed from .3 to .2 at 3am last night and is still on that...
-
For anyone wanting to sniff wifi traffic on the Raspberry Pi without Broadlink this is a useful tool https://www.raspberrypi.org/forums/viewtopic.php?t=152867?
Mike have you set a static ip for your Broadlink. Are you using iPv6 or IPv4 on your system. How does your provider assign ip addresses.
-
Hey Tuicemen, you ever have an issue where your broadlink changes IP addresses? Mine seems to be bouncing from 192.168.0.3 (normal) to 192.168.0.2... and back. It changed from .3 to .2 at 3am last night and is still on that...
Yep, but this is easily fixed by going into your router and do a IP reservation for the mac address of the broadlink.
Since you can't setup the Broadlink internally with a static IP you have to have the router do it. In fact all static IPs should be done from the router so an IP isn't assigned to something else before the device tries to activate its connection. >!
-
Yep, but this is easily fixed by going into your router and do a IP reservation for the mac address of the broadlink.
Since you can't setup the Broadlink internally with a static IP you have to have the router do it. In fact all static IPs should be done from the router so an IP isn't assigned to something else before the device tries to activate its connection. >!
I wish I could do this but my router is not smart enough to do that.
I installed e-control and it will not learn any Rf codes. Neither will broadliink app. I was able to import a whole batch of X10 commands from someone else who shared theirs and they seem to send ok. Not sure why I can no longer teach rf to the RM2.
-
Yep, but this is easily fixed by going into your router and do a IP reservation for the mac address of the broadlink.
Since you can't setup the Broadlink internally with a static IP you have to have the router do it. In fact all static IPs should be done from the router so an IP isn't assigned to something else before the device tries to activate its connection. >!
I wish I could do this but my router is not smart enough to do that.
the setting is usually found under the DHCP Server setup and sometimes can be refered to as "static IP leases" which my dsl router does. My cable router refers to it as IP reservations but it is still under the DHCP server setup.
-
I have such a DUMB model/router, it even has a well documented problem of stepping on its own toes many times a day with a major memory leak, requiring reboots many times per day. Official Verizon product....
I had asked the mfgr, Actiontec, over a year ago when this first came up with hG and they assured me this modem did not have leases I could set or assign.
Anyway, in checking again today, I found the IQrouter and a thread showing folks just setting my 784 modem into bridge mode and letting the IQrouter handle the rest - it surelly will let me preassign IP to MACs... going to check then buy one today...
-
Many ISP will replace their modem/routers with the newer model free of charge, they currently issue they just don't advertise it.
Call them up and ask for a replacement and see what they say. >!
-
I don't know what the monthly fee is for the Verizon modem but you might want to buy your own modem and router. I have Comcast and they charge about $11/mo for a cable modem/router combo but I bought my own modem for $70 plus a good router for $80 and it all paid for itself in 14 months - and that was 5 years ago! Even if it breaks every 15 months (it won't) you'd still be ahead of the game. Then you can configure your router anyway you like and upgrade it as the need arises. I'm pretty sure you can do the same with Verizon as I see the "Verizon compatible" DSL modems at all the usual places. I use a Motorola modem and an Asus router.
-
yep, I stopped renting Verizon's ($10/mo IIRC) years ago also. My last buy seemed highly recommended (Actiontec GT784) and has been the worst one I ever owned; they have a memory leak that causes it to lock up multiple times daily and they have not fixed it for the year I have owned it. Plenty of 'reboot' problems listed on line about it.
Anyway this IQrouter sounds like the latest and greatest; keep my crappy 784 and just turn off it's wireless & set DMZ to send all directly to the new IQrouter.
-
You could have the "best of/worst of" discussion on the subject of routers and still not reach a consensus. What is interesting is this approach which a number of colleagues have used to liberate their routers and unleash their full potential. It's worth checking out what routers are compatible with this approach https://www.flashrouters.com/learn/router-basics/what-is-dd-wrt
-
If you really want to go the DIY Pi route https://www.raspberrypi.org/forums/viewtopic.php?t=141578
You can see how versatile the Raspberry Pi becomes in this case. Gotta a problem, getta Pi :)
-
You could have the "best of/worst of" discussion on the subject of routers and still not reach a consensus. What is interesting is this approach which a number of colleagues have used to liberate their routers and unleash their full potential. It's worth checking out what routers are compatible with this approach https://www.flashrouters.com/learn/router-basics/what-is-dd-wrt
Agreed. DD-WRT or options like Tomato let you really optimize your router. Been running it for years.
-
You could have the "best of/worst of" discussion on the subject of routers and still not reach a consensus. What is interesting is this approach which a number of colleagues have used to liberate their routers and unleash their full potential. It's worth checking out what routers are compatible with this approach https://www.flashrouters.com/learn/router-basics/what-is-dd-wrt
Agreed. DD-WRT or options like Tomato let you really optimize your router. Been running it for years.
That experience will be invaluable here. Free your router :)%
-
DDWRT here for years. I should update to a newer router since my Linksys WRT routers are not exactly cutting edge, but they work so well with DDWRT that I'd require the new one have that available. Almost pulled the plug last month when Amazon had a gigabit router on sale, but turned out not compatible.
Anyone know of a gigabit router with wifi that doesn't cost a million dollars and supports DDWRT? I have 2 routers currently installed to get full wifi coverage.
-
So I have enough codes now in e-control to do everything I want. I was able to build anew ARM and DISARM as I want, and, in e-control on my phone, I can arm and disarm my DS7000.
So all I need is to move the codes from android over to my pi.
A decent sounding decipher program is:
https://github.com/NightRang3r/Broadlink-e-control-db-dump/blob/master/getBroadlinkSharedData.py
But I cannot make it run on my pi...
Can someone help me figure out how to run this python program?
If not, I can spend another few hours and decode the files myself. I already downloaded them from my phone onto the pi, but there are 40 of them, and without this decoder to splice 3 files worth of data together, it will take me hours to experiment and find which 2 out of the 40 I want...
-
said another way, it appears they want me to 'run a script.'
I am assuming the script is the C type program shown. In this case it is:
-----------------------------------------------------
# -*- coding: utf-8 -*-
'''
This script will "parse" the broadlink e-Control Android application "SharedData" json files and dump the IR / RF codes for selected accessories into a text file which can be later used with broadlink-python to send the codes to the RM PRO hub
NO ROOT ACCESS REQUIRED
Just connect your Android device to your computer and browse the SD card / External Storage folder "/broadlink/newremote/SharedData/"
You need to get the following files:
jsonSubIr
jsonButton
jsonIrCode
and put them in the same folder as this script.
run: python getBroadlinkSharedData.py
or duplicate code by number
python getBroadlinkSharedData.py 5
'''
import simplejson as json
import base64, sys
if len(sys.argv) > 1:
MultipleCode = sys.argv[1]
else:
MultipleCode = "1"
buttonIDS = []
buttonNames = []
jsonSubIr = open("jsonSubIr").read()
jsonSubIrData = json.loads(jsonSubIr)
for i in range(0, len(jsonSubIrData)):
print "ID:", jsonSubIrData['id'], "| Name:", jsonSubIrData['name']
choice = input("Select accessory ID: ")
for i in range(0, len(jsonSubIrData)):
if jsonSubIrData['id'] == choice:
accessory_name = jsonSubIrData['name']
print "- You selected: ", accessory_name
jsonButton = open("jsonButton").read()
jsonButtonData = json.loads(jsonButton)
for i in range(0, len(jsonButtonData)):
if jsonButtonData['subIRId'] == choice:
buttonIDS.append(jsonButtonData['id'])
buttonNames.append(jsonButtonData['name'])
jsonIrCode = open("jsonIrCode").read()
jsonIrCodeData = json.loads(jsonIrCode)
print "- Dumping codes to " + accessory_name + ".txt"
codesFile = open(accessory_name + '.txt', 'w')
for i in range(0, len(jsonIrCodeData)):
for j in range(0, len(buttonIDS)):
if jsonIrCodeData['buttonId'] == buttonIDS[j]:
code = ''.join('%02x' % (i & 0xff) for i in jsonIrCodeData['code']) * int(MultipleCode)
code_base64 = code.decode("hex").encode("base64")
result = "Button Name: " + buttonNames[j] + "\r\n" + "Button ID: " + str(jsonIrCodeData['buttonId']) + "\r\n" + "Code: " + code + "\r\n" + "Base64: " + "\r\n" + code_base64 + "\r\n"
codesFile.writelines(result.encode('utf-8'))
----------------------------------------------------
So, how do I run it? do i copy the above into a text file and name it "getBroadlinkSharedData.py "?
then in SSH window type:
getBroadlinkSharedData.py
or
python getBroadlinkSharedData.py
or
run python getBroadlinkSharedData.py ???
This is crazy!
-
Well, guess necessity makes things happen... I had to learn how to do this... So I copied it to a file, and learned a python program runs by calling it from command line as python scriptname...
I imported all 40 codes from my phone to a directory on my pi. Now I can make a bunch of IR buttons and then come back and copy/paste MY codes over into each of them.
Pretty round about way but at least it will get it don while waiting on broadlink plugin author getting RF and import functions to work.
-
domoticz now sends security commands :) I can arm and disarm... AHP days may be numbered...
I need to make a new backup image, so will change my pi pw back to raspberry and make it then post link to the image on my dropbox.
-
Python as you have now discovered is a very powerful and versatile language. In most cases when you find a program on the GitHub you can write a python wrapper to use it in your setup.
Now that you have a functioning setup running as you require you can further expand it via the Domoticz forum and of course the many Python resources on the web.
You might want to research the possibility of creating a Python Docker image of your setup as it is easier to distribute. Alternatively you could package it in a Python Virtualenv for convenience. Plenty of documentation out there on both alternatives.
-
Mike, on a side note, ensure your credentials are not included on any image you upload. It's an easy thing to overlook but fatal if it happens.
-
See this article re Python security issues.
https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/ (https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/)
-
Mike, on a side note, ensure your credentials are not included on any image you upload. It's an easy thing to overlook but fatal if it happens.
I just made a backup image, now writing another 8gb card with it - I will then go in and change pi pw back & remove my wifi info, write THAT image for distribution to anyone who wants to try it.
BUT I while it is writing the new SD card to remove p's from, I weill investigate your other programs - tnx.
Dave, thanks for the security check article - reading now...
-
Back to the drawing board... I installed simplejson in order to run a python program to dice my X10 e-control codes into hex commands more easily... I assume that is what brock mochad... after a reboot (due to shutting down to make final image) of a totally running system, mochad no longer worked...
Eventually I deleted the mochad-0.1.17 full directory and reintalled ver 1.16 and after messing around got it to work again. But not wanting 1.16, I deleted that and reinstalled 1.17 and got it working again. a reboot and IIRC I think it till worked... But a couple hours later mochad was unresponsive again. Reboot did not bring it back - cannot find cm15.
I hate it when more than 1 thing happens between issues: I had just finished programming a neat 60 watt smart LED lightbulb (3000-5500k color adjustment, dimming, on off, timers, some other cute things, all over the wifi network) - on the same power strip as my cm15 tester... So for a while I thought the smart LED killed my cm15. A quick plug in into AHP proved it was still good.
I think I reimaged my card from good last image and mochad was still NFG, but can't swear to it now.. I think I also reinstalled mochad 2x and each time got it to work - for an hour or so...
Glad I am keeping running copies of my images... back to the drawing board...
-
Can anyone help me decode why mochad is disconnecting? Here are my 3 clues so far:
1) nc localhost 1099 - opens watching ALL x10 commands seen by the CM15... I can walk around the house triggering motion sensors and they all show up as seen. On and off. Ditto if I use a remote control and send codes. So the CM15 IS interfacing...
10/28 15:04:03 Rx PL HouseUnit: B10
10/28 15:04:03 Rx PL House: B Func: Off
10/28 15:04:49 Rx PL House: B Func: On
BUT ONLY after it starts working by new boot sometimes, or if I manually start the service (I think) by ./mochad
2) ./mochad - but mochad reports no CM15 found if run this way...
Message from syslogd@raspberrypi at Oct 28 15:01:47 ...
mochad[3072]: libusb_open_device_with_vid_pid failed
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-28 15:01:47 EDT):
mochad[3072]: libusb_open_device_with_vid_pid failed
Message from syslogd@raspberrypi at Oct 28 15:01:47 ...
mochad[3072]: Could not find/open CM15A/CM19A -5
Broadcast message from systemd-journald@raspberrypi (Sun 2018-10-28 15:01:47 EDT):
mochad[3072]: Could not find/open CM15A/CM19A -5
3) sudo systemctl status mochad - reports it IS seen!??
● mochad.service - Start mochad service
Loaded: loaded (/lib/systemd/system/mochad.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2018-10-28 15:01:27 EDT; 37s ago
Process: 3068 ExecStart=/usr/local/bin/mochad (code=exited, status=0/SUCCESS)
Main PID: 3069 (mochad)
CGroup: /system.slice/mochad.service
└─3069 /usr/local/bin/mochad
Oct 28 15:01:27 raspberrypi systemd[1]: Starting Start mochad service...
Oct 28 15:01:27 raspberrypi mochad[3068]: starting
Oct 28 15:01:27 raspberrypi systemd[1]: Started Start mochad service.
Oct 28 15:01:27 raspberrypi mochad[3069]: Found CM15A
Oct 28 15:01:27 raspberrypi mochad[3069]: In endpoint 0x81, Out endpoint 0x02
PS -A or aux generally shows mochad running...
---------------------------------------------------------------------------
So this is with ver 1.17... I tried 1.16 and too many things have been tried for me to even recall why it did not work consistently...
Any ideas?
-
Have you set up Mochad as a background daemon service as I mentioned in a previous post. Working on initial boot and the stopping is classic symptoms of Mochad service being setup incorrectly. Post a copy of your Mochad.service file
-
This is a start to finish post of Mochad and Domoticz. Might be worth reading from start to finish to troubleshoot your problem https://www.sigmdel.ca/michel/ha/x10/domoticz_install_03_en.html
There has been reports of problems with Mochad locking up when sensors were sending commands back to Mochad.
I’d really try and get Mochad working fully before integrating it into Domoticz.
-
Actually that is the guide I do use, so it was followed exactly...
I have see cases where it will work one time sending an echo a1 on | nc ...1099 command then lock up. I have seen times it never does anything. ps -A shows mochad in its list after plugging in the cm15.
/home/pi/mochad/mochad-0.1.17/mochad.service is this:
[Unit]
Description=Start mochad service
[Service]
Type=forking
ExecStart=/usr/local/bin/mochad
[Install]
WantedBy=multi-user.target
-
Actually that is the guide I do use, so it was followed exactly...
I have see cases where it will work one time sending an echo a1 on | nc ...1099 command then lock up. I have seen times it never does anything. ps -A shows mochad in its list after plugging in the cm15.
/home/pi/mochad/mochad-0.1.17/mochad.service is this:
[Unit]
Description=Start mochad service
[Service]
Type=forking
ExecStart=/usr/local/bin/mochad
[Install]
WantedBy=multi-user.target
Where's your restart command in the service file
Here's a sample of a Mochad service daemon file you'd probably need to keep Mochad running on failure. You'll have to make adjustments to suit your own purposes.
[Unit]
Description=Mochad X10 Daemon
Requires=systemd-udevd.service
Wants=network.target
After=systemd-udevd.service network.target
[Service]
Type=forking
GuessMainPID=yes
ExecStart=/usr/local/bin/mochad
TimeoutStartSec=6
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
-
http://forums.x10.com/Smileys/default/headbanging.gif How I feel about Mochad at this point...
Thanks, I will add your restart stuff to the file, just one question: ADD TO WHICH FILE?
I found that same file in the mochad directory as I showed, but it is also in some other root location - IIRC it was maybe /etc/local
Oh never mind, I will just modify it in BOTH locations.
THANKS.
Last experimenting I could send echo a1 on | nc ...1099 and that left the command active so I could see everytime cm15 saw and reported a command from elsewhere. Ie., I could push remote pad buttons and mochad would show them as they happened in the SSH window... so I knew the cm15 was talking back to Mochad. BUT the echo command I typed in for mochad to SEND to the cm15 was indeed echoed back on the screen, but no command went out of the cm15 to the pl... like mochad is running but not its service - if there are two different programs supposed to be running at the same time?
-
Add those lines to mochad.service which should be stored at /etc/systemd/system. Please ensure you don't have two incidences of mochad.service running. Just type sudo systemctl status mochad.service to ensure the service is running correctly.
Once you have a correctly constructed service daemon running on boot Mochad runs in the background until it is called upon. Again sudo systemctl status mochad.service to check all is working fine. One service only required to handle Mochad.
-
not in /etc/systemd/system... but here:
/home/pi/mochad/mochad-0.1.17/systemd/mochad.service
/lib/systemd/system/mochad.service
And it is running; THIS is the one that is hooked to the cm15 I think... It is mochad app program?? that is not hooked to it, if this makes sense?
The following is typical and still cm15 not working:
pi@raspberrypi:~ $ systemctl status mochad.service
● mochad.service - Start mochad service
Loaded: loaded (/lib/systemd/system/mochad.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2018-10-28 18:01:45 EDT; 21h ago
Process: 3612 ExecStart=/usr/local/bin/mochad (code=exited, status=0/SUCCESS)
Main PID: 3613 (mochad)
CGroup: /system.slice/mochad.service
└─3613 /usr/local/bin/mochad
Oct 28 18:01:45 raspberrypi systemd[1]: Starting Start mochad service...
Oct 28 18:01:45 raspberrypi mochad[3612]: starting
Oct 28 18:01:45 raspberrypi systemd[1]: Started Start mochad service.
Oct 28 18:01:45 raspberrypi mochad[3613]: Found CM15A
Oct 28 18:01:45 raspberrypi mochad[3613]: In endpoint 0x81, Out endpoint 0x02
pi@raspberrypi:~ $
Not working as shown by this command:
pi@raspberrypi:~ $ echo "pl b10 off" | nc localhost 1099
^Z [<<-- I have to push this to close this and return to pi command line...]
[2]+ Stopped echo "pl b10 off" | nc localhost 1099
pi@raspberrypi:~ $
So mochad.service is running, connected to cm15, but mochad (the python script? program?) is not hooked to the service?
-
I've changed them both... no difference...
I went back into AHP and cleared memory again... no change
I went in and changed it to transceive RF, no change
Sending echo... nc does nothing
systemctl check shows cm15 active and hooked up...
echo nc... does nothing now after reboots... If I didn't realize there is something ELSE going on here, I would think the added restart stuff is causing it to be worse again...
but again, mochad service is running solid, with access to the cm15, it is just the echo a1 off | nc is NOT sending the pl asked to send...
http://forums.x10.com/Smileys/default/headbanging.gif
http://forums.x10.com/Smileys/default/BDH.gif
-
Can you turn a light on and off using Mochad directly
-
After you have rebooted your Pi what happens when you type these two commands at the terminal prompt. Change the house codes for the ones you are using
$ echo "pl a1 on" | nc localhost 1099
$ echo "pl a1 off" | nc locahost 1099
btw you have a mochad.service file located here /home/pi/mochad/mochad-0.1.17/systemd/mochad.service. It shouldn't be there but I'm assuming it hasn't been enabled so it's doing no damage.You edit the mochad.service file located at /lib/systemd/system/mochad.service and that's it. Be careful what folders you are using to create files in.
-
i am not creating ANY folders; I am not copying or creating any files. All the mochad stuff on my pi are from its own installation!
I will circle back to answer your question in another post; sometimes it shows sending the codes and nothing happens, other times it shows nothing. when it does show sending the codes, if I send 10 from another source it shows up in the list... until I quit it with ^z.
I am convinced the cm15 is being attached to a version of mochad first run then stopped for whatever reason, and future restarted versions of mochad try to attach to another copy of cm15, but by then it is too late - cm15 is already attached to the first process that no longer is running so not available to future copies of mochad. or something along these lines... I can seee what appears to be multiple PID copies of cm15 being assigned in the /var/log/messages file:
Oct 29 15:40:10 raspberrypi kernel: [ 2.263007] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
Oct 29 15:40:10 raspberrypi kernel: [ 2.403953] usb 1-1.4: New USB device found, idVendor=0409, idProduct=005a
Oct 29 15:40:10 raspberrypi kernel: [ 2.411591] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 29 15:40:10 raspberrypi kernel: [ 2.422591] hub 1-1.4:1.0: USB hub found
Oct 29 15:40:10 raspberrypi kernel: [ 2.431550] hub 1-1.4:1.0: 4 ports detected
Oct 29 15:40:10 raspberrypi kernel: [ 2.502996] usb 1-1.1.2: new low-speed USB device number 5 using dwc_otg
Oct 29 15:40:10 raspberrypi kernel: [ 2.651933] usb 1-1.1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 15:40:10 raspberrypi kernel: [ 2.659459] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 15:40:10 raspberrypi mtp-probe: bus: 1, device: 6 was not an MTP device
Oct 29 15:40:10 raspberrypi liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="218" x-info="http://www.rsyslog.com"] start
Oct 29 15:40:10 raspberrypi kernel: [ 2.666883] usb 1-1.1.2: Product: USB ActiveHome Interface
Oct 29 15:40:10 raspberrypi kernel: [ 2.674260] usb 1-1.1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 15:40:10 raspberrypi kernel: [ 2.697793] NET: Registered protocol family 10
Oct 29 15:40:10 raspberrypi kernel: [ 2.707294] Segment Routing with IPv6
Oct 29 15:40:10 raspberrypi kernel: [ 2.731695] ip_tables: (C) 2000-2006 Netfilter Core Team
Oct 29 15:40:10 raspberrypi kernel: [ 2.766053] random: systemd: uninitialized urandom read (16 bytes read)
Oct 29 15:40:10 raspberrypi kernel: [ 2.910969] random: systemd: uninitialized urandom read (16 bytes read)
Oct 29 15:40:10 raspberrypi kernel: [ 3.183059] usb 1-1.1.3: new full-speed USB device number 6 using dwc_otg
Oct 29 15:40:10 raspberrypi kernel: [ 3.199094] random: systemd-gpt-aut: uninitialized urandom read (16 bytes read)
Oct 29 15:40:10 raspberrypi kernel: [ 3.338641] usb 1-1.1.3: New USB device found, idVendor=062a, idProduct=4c01
Oct 29 15:40:10 raspberrypi kernel: [ 3.347104] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 15:40:10 raspberrypi kernel: [ 3.355388] usb 1-1.1.3: Product: 2.4G Keyboard Mouse
Oct 29 15:40:10 raspberrypi kernel: [ 3.363705] usb 1-1.1.3: Manufacturer: MOSART Semi.
Oct 29 15:40:10 raspberrypi kernel: [ 3.394495] input: MOSART Semi. 2.4G Keyboard Mouse as /devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0/0003:062A:4C01.0001/input/input0
Oct 29 15:40:10 raspberrypi kernel: [ 3.474123] hid-generic 0003:062A:4C01.0001: input,hidraw0: USB HID v1.10 Keyboard [MOSART Semi. 2.4G Keyboard Mouse] on usb-20980000.usb-1.1.3/input0
Oct 29 15:40:10 raspberrypi kernel: [ 3.523132] input: MOSART Semi. 2.4G Keyboard Mouse as /devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.1/0003:062A:4C01.0002/input/input1
Oct 29 15:40:10 raspberrypi kernel: [ 3.594192] hid-generic 0003:062A:4C01.0002: input,hiddev96,hidraw1: USB HID v1.10 Mouse [MOSART Semi. 2.4G Keyboard Mouse] on usb-20980000.usb-1.1.3/input1
Oct 29 15:40:10 raspberrypi kernel: [ 7.499851] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Oct 29 15:40:10 raspberrypi kernel: [ 11.727161] usbcore: registered new interface driver brcmfmac
Oct 29 15:40:10 raspberrypi kernel: [ 12.221696] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
Oct 29 15:40:10 raspberrypi kernel: [ 12.316639] bcm2835_alsa bcm2835_alsa: card created with 8 channels
Oct 29 15:40:10 raspberrypi kernel: [ 14.415832] random: crng init done
Oct 29 15:40:10 raspberrypi kernel: [ 14.415861] random: 7 urandom warning(s) missed due to ratelimiting
Oct 29 15:40:11 raspberrypi kernel: [ 16.185216] uart-pl011 20201000.serial: no DMA platform data
Oct 29 15:40:13 raspberrypi kernel: [ 18.721255] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
Oct 29 15:40:15 raspberrypi kernel: [ 20.543052] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 29 15:40:15 raspberrypi kernel: [ 20.543101] brcmfmac: power management disabled
Oct 29 15:40:15 raspberrypi kernel: [ 20.685380] Bluetooth: Core ver 2.22
Oct 29 15:40:15 raspberrypi kernel: [ 20.685524] NET: Registered protocol family 31
Oct 29 15:40:15 raspberrypi kernel: [ 20.685532] Bluetooth: HCI device and connection manager initialized
Oct 29 15:40:15 raspberrypi kernel: [ 20.685559] Bluetooth: HCI socket layer initialized
Oct 29 15:40:15 raspberrypi kernel: [ 20.685573] Bluetooth: L2CAP socket layer initialized
Oct 29 15:40:15 raspberrypi kernel: [ 20.685619] Bluetooth: SCO socket layer initialized
Oct 29 15:40:15 raspberrypi kernel: [ 20.703568] Bluetooth: HCI UART driver ver 2.3
Oct 29 15:40:15 raspberrypi kernel: [ 20.703640] Bluetooth: HCI UART protocol H4 registered
Oct 29 15:40:15 raspberrypi kernel: [ 20.703647] Bluetooth: HCI UART protocol Three-wire (H5) registered
Oct 29 15:40:15 raspberrypi kernel: [ 20.706302] Bluetooth: HCI UART protocol Broadcom registered
Oct 29 15:40:16 raspberrypi kernel: [ 21.313022] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Oct 29 15:40:16 raspberrypi kernel: [ 21.313037] Bluetooth: BNEP filters: protocol multicast
Oct 29 15:40:16 raspberrypi kernel: [ 21.313066] Bluetooth: BNEP socket layer initialized
Oct 29 15:40:16 raspberrypi kernel: [ 21.850149] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 29 15:40:22 raspberrypi mochad[425]: starting
Oct 29 15:40:22 raspberrypi mochad[427]: Found CM15A
Oct 29 15:40:22 raspberrypi mochad[427]: In endpoint 0x81, Out endpoint 0x02
Oct 29 15:40:23 raspberrypi domoticz: Domoticz is starting up....
Oct 29 15:40:23 raspberrypi domoticz: Domoticz running...
Oct 29 15:40:53 raspberrypi mochad[523]: starting
Oct 29 15:40:53 raspberrypi mochad[524]: Found kernel driver 0, trying detach
Oct 29 15:40:53 raspberrypi mochad[524]: terminated
Oct 29 16:06:07 raspberrypi kernel: [ 1562.443220] usb 1-1.1.2: USB disconnect, device number 5
Oct 29 16:08:37 raspberrypi kernel: [ 1712.784421] usb 1-1.2: new low-speed USB device number 7 using dwc_otg
Oct 29 16:08:37 raspberrypi kernel: [ 1712.922889] usb 1-1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 16:08:37 raspberrypi kernel: [ 1712.922915] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 16:08:37 raspberrypi kernel: [ 1712.922928] usb 1-1.2: Product: USB ActiveHome Interface
Oct 29 16:08:37 raspberrypi kernel: [ 1712.922941] usb 1-1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 16:08:37 raspberrypi mtp-probe: checking bus 1, device 7: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.2"
Oct 29 16:08:37 raspberrypi mtp-probe: bus: 1, device: 7 was not an MTP device
Oct 29 16:09:10 raspberrypi kernel: [ 1745.515652] usb 1-1.2: USB disconnect, device number 7
Oct 29 16:09:13 raspberrypi kernel: [ 1748.596759] usb 1-1.1.2: new low-speed USB device number 8 using dwc_otg
Oct 29 16:09:13 raspberrypi kernel: [ 1748.734981] usb 1-1.1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 16:09:13 raspberrypi kernel: [ 1748.735010] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 16:09:13 raspberrypi kernel: [ 1748.735025] usb 1-1.1.2: Product: USB ActiveHome Interface
Oct 29 16:09:13 raspberrypi kernel: [ 1748.735037] usb 1-1.1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 16:09:13 raspberrypi mtp-probe: checking bus 1, device 8: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.2"
Oct 29 16:09:13 raspberrypi mtp-probe: bus: 1, device: 8 was not an MTP device
Oct 29 16:10:08 raspberrypi kernel: [ 1803.339868] usb 1-1.1.2: USB disconnect, device number 8
Oct 29 16:11:18 raspberrypi kernel: [ 1874.034122] usb 1-1.1.2: new low-speed USB device number 9 using dwc_otg
Oct 29 16:11:18 raspberrypi kernel: [ 1874.172474] usb 1-1.1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 16:11:18 raspberrypi kernel: [ 1874.172502] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 16:11:18 raspberrypi kernel: [ 1874.172515] usb 1-1.1.2: Product: USB ActiveHome Interface
Oct 29 16:11:18 raspberrypi kernel: [ 1874.172527] usb 1-1.1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 16:11:19 raspberrypi mtp-probe: checking bus 1, device 9: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.2"
Oct 29 16:11:19 raspberrypi mtp-probe: bus: 1, device: 9 was not an MTP device
Oct 29 16:12:26 raspberrypi mochad[635]: starting
Oct 29 16:12:26 raspberrypi mochad[636]: terminated
Oct 29 16:12:32 raspberrypi mochad[638]: starting
Oct 29 16:12:32 raspberrypi mochad[639]: terminated
Oct 29 16:12:59 raspberrypi mochad[646]: starting
Oct 29 16:12:59 raspberrypi mochad[647]: terminated
Oct 29 16:29:15 raspberrypi kernel: [ 2951.246758] usb 1-1.1.2: USB disconnect, device number 9
Oct 29 16:29:25 raspberrypi kernel: [ 2961.272716] usb 1-1.1.2: new low-speed USB device number 10 using dwc_otg
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411059] usb 1-1.1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411088] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411101] usb 1-1.1.2: Product: USB ActiveHome Interface
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411112] usb 1-1.1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 16:29:26 raspberrypi mtp-probe: checking bus 1, device 10: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.2"
Oct 29 16:29:26 raspberrypi mtp-probe: bus: 1, device: 10 was not an MTP device
Oct 29 17:45:25 raspberrypi mochad[427]: detaching CM15A
Oct 29 17:45:25 raspberrypi mochad[427]: terminated
Oct 29 17:45:28 raspberrypi mochad[699]: starting
Oct 29 17:45:28 raspberrypi mochad[700]: Found CM15A
Oct 29 17:45:28 raspberrypi mochad[700]: In endpoint 0x81, Out endpoint 0x02
-
I swear mochad cannot find the cm15 even tho it says found in momchad.service! this var/log/messages seems to say it:
Oct 29 16:29:15 raspberrypi kernel: [ 2951.246758] usb 1-1.1.2: USB disconnect, device number 9
Oct 29 16:29:25 raspberrypi kernel: [ 2961.272716] usb 1-1.1.2: new low-speed USB device number 10 using dwc_otg
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411059] usb 1-1.1.2: New USB device found, idVendor=0bc7, idProduct=0001
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411088] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411101] usb 1-1.1.2: Product: USB ActiveHome Interface
Oct 29 16:29:26 raspberrypi kernel: [ 2961.411112] usb 1-1.1.2: Manufacturer: X10 Wireless Technology Inc
Oct 29 16:29:26 raspberrypi mtp-probe: checking bus 1, device 10: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1.2"
Oct 29 16:29:26 raspberrypi mtp-probe: bus: 1, device: 10 was not an MTP device
Oct 29 17:45:25 raspberrypi mochad[427]: detaching CM15A
Oct 29 17:45:25 raspberrypi mochad[427]: terminated
Oct 29 17:45:28 raspberrypi mochad[699]: starting
Oct 29 17:45:28 raspberrypi mochad[700]: Found CM15A
Oct 29 17:45:28 raspberrypi mochad[700]: In endpoint 0x81, Out endpoint 0x02
Oct 29 20:13:10 raspberrypi mochad[1971]: starting
Oct 29 20:13:11 raspberrypi mochad[1971]: Found kernel driver 0, trying detach
Oct 29 20:13:11 raspberrypi mochad[1971]: terminated
Oct 29 20:14:14 raspberrypi mochad[1981]: starting
Oct 29 20:14:14 raspberrypi mochad[1982]: Found kernel driver 0, trying detach
Oct 29 20:14:14 raspberrypi mochad[1982]: terminated
Oct 29 20:19:04 raspberrypi mochad[2005]: starting
Oct 29 20:19:04 raspberrypi mochad[2006]: Found kernel driver 0, trying detach
Oct 29 20:19:04 raspberrypi mochad[2006]: terminated
each 3 line failure at end is from sending ./mochad command in terminal window...
-
What's the output from dmesg and lsusb now.
-
Can you revert to an image that Mochad is known to work on. Your current install looks broken to me.
Mochad really is easy to install. You create the makefile, build it and install it. You then plug in your CM15 and you're ready to go. After that you create the service daemon to launch Mochad on boot.
-
Did you install mochad prior to Domoticz?
I read somewhere it has to be installed prior or you'll have issues
-
What's the output from dmesg and lsusb now.
interesting logs. attached.
-
Did you install mochad prior to Domoticz?
I read somewhere it has to be installed prior or you'll have issues
Good question; I recall seeing that also and doing so IN THE PAST... Let me check my timeline.
ooooooops.
back tot he drawing board....
-
Mike I was at pains to mention that you get Mochad fully working on a vanilla Raspbian Stretch Lite prior to installing ANYTHING else. Mochad working means that it is actually functioning and the mochad.service has been created to ensure that it is running as a service daemon on boot.
You can't keep installing different versions of Mochad without first fully deleting the previous version. As you are building from source unless the author has created an uninstaller you physically have to remove every trace of the program manually. You are installing outside the aptitude manager so these processes need to be addressed manually.
I strongly suggest you start again and follow the clearly outlined steps to achieve a fully functioning X10 in Domoticz.
If you read back over my posts you'll see that I asked you a number of questions which you never replied to. This is the only way to truly troubleshoot the issues you are experiencing.
-
It is a shame such an important program as mochad cannot coexist well with other programs. Of course since I need it I will start fresh and make mochad the FIRST thing installed. Shame.
-
Actually mochad works fine it is the way Domoticz uses it that is causing the issue.
If you loaded just mochad as petera suggested on a clean Raspbian install with out Domoticz and played with it first you'd see how it performed. Adding everything at once and then testing only leads to issues which are hard to trouble shoot.
I had no issue using mochad with Domoticz while testing Domoticz operation, however for me HomeGenie was the better fit.
-
Mochad as stand alone, not thru domoticz, fails to function properly; apparently it fails to install itself properly when installed on a pi with other programs installed before it. ALL my last weeks worth of testing has been with just mochad functionality, not thru domoticz.
You can see from my previous post that I methodically added only ONE program at a time to my pi. I learned early on that doing more than 1 thing at a time was not possible on the limited linux system. That is why I always added only 1 program at a time and tested it to make sure it worked, made an image of the working system, before going on to the next addition. Mochad worked when installed, just failed to be consistent after reboots.
I have gone back to a fresh copy of just updated and upgraded pi. I am going to add mochad FIRST and test, reboot, test, reboot for days before adding the next program.
-
Mike, it might be worth joining in the efforts to get the X10 Pi Hub project off the ground. You have proved that you are determined to stick with things till you get results and Homegenie will provide you with nearly everything that Domoticz does and maybe a bit more now that we have a collaboration underway.
-
Mochad as stand alone, not thru domoticz, fails to function properly; apparently it fails to install itself properly when installed on a pi with other programs installed before it. ALL my last weeks worth of testing has been with just mochad functionality, not thru domoticz.
You can see from my previous post that I methodically added only ONE program at a time to my pi. I learned early on that doing more than 1 thing at a time was not possible on the limited linux system. That is why I always added only 1 program at a time and tested it to make sure it worked, made an image of the working system, before going on to the next addition. Mochad worked when installed, just failed to be consistent after reboots.
I have gone back to a fresh copy of just updated and upgraded pi. I am going to add mochad FIRST and test, reboot, test, reboot for days before adding the next program.
Mike, there seems to be some confusion over the Raspbian Lite version and the Raspbian Desktop version.
As I mentioned before, the Lite version and the Desktop version will will pull in any dependencies that are required via the package manager for any particular package you wish to install. It checks firstly to see if those dependencies are installed and will NOT install them if they are already present.
If you choose to compile a program and install it yourself outside the package manager the author will usually point out what dependencies are required to be installed in addition to the compiled program. What it will not do is check if those dependencies are already installed. Hence the instances of duplicate programs with different version numbers with your install.
It looks like you were compiling programs from links that didn't have clear installation instructions. Those links are usually aimed at proficient Linux users who know what they are after and don't need to ask the questions that you may need to ask.
I suggest you take each step slowly and thoroughly test it before moving on to the next one. It's Mochad first, Domoticz and then the RM Link. Again it's entirely up to yourself how you progress but using the method I mentioned will save you hours of hair pulling.
-
petera, you keep saying that I am doing things outside the norm, like compiling all kinds of different programs and mixing and matching incompatible programs. I am not sure where those ideas came from. I have never tried to install weird off the wall programs. I have never tried to compile anything other than following detailed exact step by step how to's for installing mochad. when ver 1.17 seemed bad I usually reimaged and started over, following again the exact steps to install ver 1.16. so i am confused by your saying I am mixing and compiling different things.
yes, at the end here i did delete mochad-0.1.17 directory and reinstall mochad-0.1.16, then try again with 1.17 in utter desperation to make an errant program get along with others.
I reimaged another new stretch lite 8gb SD card and I will install mochad first. Since I ALWAYS do one thing at a time, I will continue and do so next again. But this time I will leave mochad alone on the SD card and exercise it thru many reboots and testing for days before adding the next program. I suspect it will not survive 2-3 days of exercises, even alone on a pi. If this proves the case, I will have no recourse but to scrap domoticz and go back to the kluge of HG & Habridge since it does not rely on the poorly executed mochad.
-
petera, you keep saying that I am doing things outside the norm, like compiling all kinds of different programs and mixing and matching incompatible programs. I am not sure where those ideas came from. I have never tried to install weird off the wall programs. I have never tried to compile anything other than following detailed exact step by step how to's for installing mochad. when ver 1.17 seemed bad I usually reimaged and started over, following again the exact steps to install ver 1.16. so i am confused by your saying I am mixing and compiling different things.
yes, at the end here i did delete mochad-0.1.17 directory and reinstall mochad-0.1.16, then try again with 1.17 in utter desperation to make an errant program get along with others.
I reimaged another new stretch lite 8gb SD card and I will install mochad first. Since I ALWAYS do one thing at a time, I will continue and do so next again. But this time I will leave mochad alone on the SD card and exercise it thru many reboots and testing for days before adding the next program. I suspect it will not survive 2-3 days of exercises, even alone on a pi. If this proves the case, I will have no recourse but to scrap domoticz and go back to the kluge of HG & Habridge since it does not rely on the poorly executed mochad.
Mike I have Mochad working in five different home automation programs, all working fine. I set it up in Domoticz too so not sure why you think it's poorly executed.
Pulling in various versions of Python to try make a program work is only asking for trouble. Python is a whole different ball game. If a particular plugin does not work with the latest version of Python it's usually a sign that you will experience difficulties unless you are experienced in the Python environment.
I assumed you had cracked Mochad on the Raspberry Pi as you had gone ahead with Domoticz and installing the plugin for the RM Link. Again that was not the case.
You may decide to continue with Mochad/Domoticz/RM Link but you've spent a considerable amount of time and effort to get X10 up and running and the results are not ideal. Have you had any luck posting your queries on the Domoticz forum. Have you had any feedback from them. It's the best place for all things Domoticz.
Tuicemen and myself are going to give HomeGenie a crack for X10 on the Raspberry Pi. You may choose to join in with those efforts. You may find the results a bit more productive without all that effort involved with Domoticz. That's where I will be channelling all my efforts from here on in.
-
If this proves the case, I will have no recourse but to scrap domoticz and go back to the kluge of HG & Habridge since it does not rely on the poorly executed mochad.
There is always klug when your relying on different program talking to each other. but more when one relies on the other to work.
To be fair you never ( that I'm aware of) tried HG on a PI or Donmonticz on Windows. When a software states something needs to be installed prior and you then remove and reinstall it, it would be like adding AHP to windows then Uninstalling and reinstalling windows your AHP will no longer work no mater how many times you reinstall Windows.(OK not the best example but I think you see my point)
Just like Domonticz you can get other programs to work with HomeGenie and you should be able to use the Broadlink software to work with HG.
I've not looked into that option but I may during HA Season which is fast approaching.
Remember I only just created the way for HG to talk to HA-Bridge and that was done for Alexa control the Broadlink control was just a bonus.
Since you don't want or need Alexa I'd suggest playing with adding the Broadlink software controller you found with HG if you decide to drop Domoticz and move on to something else.
The Idea behind the PI X10 HUB image currently being worked on is to make for a easy setup of X10 on the Pi that stays working without the need for weekly tune ups.
I admire your persistence with Domoticz and Mochad and if you gave as much time to anyother project I'm sure it would be a benefit to all. >!
-
The theme of these endeavours was to get a credible alternative to controlling your X10 devices in light of the gaps left by X10 and all it's incarnations. The beauty of the open source philosophy is that there are so many alternatives out there you can switch to if you find that a particular solution you've chosen is too cumbersome to tailor to your needs.
Domoticz is a fine piece of work but when you start to go beyond the basics that's when you need help from the experts, the Domoticz experts. If I'm not mistaken there wouldn't be too many of them on the X10 forum. I may be wrong there of course.
What Tuicemen has formulated is a plan to build an X10 Hub along the lines of the WM100 but giving users the opportunity to provide input, suggestions and ideas on how we can proceed. He chose HomeGenie as there are a number of well seasoned experienced HomeGenie users already members on this forum.
It's by no means the "holy grail" of options out there but it looks like it might be the ideal choice for a collaborative effort. Personally I am using a heavily adapted version of Home Assistant that works for me. It might not be to everyone's taste. I do know of two users on this forum who are now up and running with it since I posted my install instructions. Those instructions may have helped them, or not but they are running X10 among other features now on it.
I am willing to assist in the X10 Pi Hub deploying HomeGenie and it would be good to see you come on board too so we could focus our efforts in one particular direction and achieve our goal.
-
Pulling in various versions of Python to try make a program work is only asking for trouble.
I assumed you had cracked Mochad on the Raspberry Pi as you had gone ahead with Domoticz and installing the plugin for the RM Link. Again that was not the case.
Just for reference, I have NOT mixed and matched different versions of python... Yes, I tried to install 3.6 and 3.7 ovr the course of this experimenting - in order to solve the fact that broadlink and its dependency python programs would just plain NOT install on ver 3.5 -- OVER FULL GUI STRETCH. THAT was the issue. When I found the LITE stretch DID allow these pyhton programs to load with the LITE version 3.5, I moved on with that. So please do not think I mixed and matched python versions; the issue was broadlink and 3 other dependent python programs would NOT load into python 3.5 ON STRETCH FULL GUI.
As for cracking mochad, I too thought I had... So I have come full circle yet again... I made a fresh stretch LITE imaged card, rand update & upgrade on it. I then used:
https://sigmdel.ca/michel/ha/domo/domo_08_en.html
to install mochad on this fresh card with no other programs installed.
YAE! It ran -- for 3 minutes.
nc localhost 1099
saw my RF CR12 presses. great!
So went on to send:
echo "pl a1 on" | nc localhost 1099
YAE! It echoed that back to me!! but but but... it did NOT send it thru the cm15...
OK, well a little fluke is ok now and then, right? So I began pressing buttons on my CR12 remote... my lites came on and off - but now the pi REPORTS NOTHING. DOESnot see them anymore...
great.
So know I KNOW mochad does NOT work on stretch lite for more than 3 minutes before locking up.
This is IDENTICAL to what I see on my full domaticz/broadlink/mochad complete card.
I now know for certain mochad 1.17 locks up by itself with no help from me. It is NOT MY FAULT. This python program has serious issues.
I am a glutten for punishment so tomorrow I will re image this card yet again and instead install mochad ver 1.16 and try again. It has been said by others that mochad 1.17 sometimes locks up and no one has any clue why...
-
I'd try this solution on a vanilla version of Raspbian Stretch Lite https://sourceforge.net/p/mochad/discussion/1320003/thread/f37816aa/
Again don't forget to add the extra wait into the nc command
echo "st" | nc -w1 localhost 1099
RF remotes have been known to lock up Mochad. Use the PL commands only and see if you can maintain Mochad functionality..
Finally as a test remove your X10 sensors from your setup and again see of you can maintain Mochad functionality.
Try each step individually so you can rules them out.
-
not sure why my description does not make it clear, but I cannot get any more vanilla that installing on a plain stretch lite image...
I cannot add the -w1 wait into each command sent as I am not the one generating the commands. Except when I do it from the command line. So to add it at control line is of no value to a 'real' app I think...
Actually I maintained mochad functionality by USING the remote... it worked all the time. it stopped working when using mochad to SEND the command AND that did not even work - even the first time!
How do I test "remove your X10 sensors from your setup?" I do not understand this since I have a vanilla stretch lite with only mochad installed. no "x10 sensors" involved...
I will revert again to older mochad... Since 1.17 has been reported to "lock up," I will give them benefit of the doubt, that the programmer knows it locks up and could not fix that. It is said ver 1.16 does not lock up - but ITS problem is reported to be not working consistently with udev so therefore not keeping mochad even running... Screwed if you do, screwed if you don't.
-
Direct quote from another user of Mochad suffering similar symptoms.......
I had this same issue and believe I found a workaround: You must turn off the CM15A setting for transcieving of RF to PL signals using ActiveHomePro, per the offical instructions. Once I did that, the Mochad lockups ceased.
Per the instructions: NOTE: CM15A macros and timers are NOT supported. For best results, use AHP (ActiveHome Pro) to clear interface memory and disable the internal RF to PL repeater. This ensures the CM15A behaves like a transceiver.
Can you confirm that you have cleared the interface AND disabled the internal RF to PL repeater in the CM15 using AHP
The sensors I refer to are the MS19a the PMS03 and such like RF sensors. Just take the batteries out of them so they are not transmitting RF X10 signals. Again trying to do a step by step troubleshoot.
The remotes have been known to cause issues too. Work a couple of times then lockup.
I assume your permissions for running Mochad are correct too. I used markvriens.com link to install and can confirm it works. Try that source as well.
-
Direct quote from another user of Mochad suffering similar symptoms.......
1) Can you confirm that you have cleared the interface AND disabled the internal RF to PL repeater in the CM15 using AHP
2) The sensors I refer to are the MS19a the PMS03 and such like RF sensors. Just take the batteries out of them so they are not transmitting RF X10 signals. Again trying to do a step by step troubleshoot.
3) The remotes have been known to cause issues too. Work a couple of times then lockup.
4) I assume your permissions for running Mochad are correct too. I used markvriens.com link to install and can confirm it works. Try that source as well.
thanks again. FYI:
1) confirmed. done many times to be sure...
2) too many to remove batts then go reprogram. If mochad does not work with motion sensors without locking up it is of no value to me.
3) If mochad does not work with remotes without locking up it is of no value to me.
4) no clue about permissions; I use sudo when told to during install and follow the install steps to the letter. markvreins steps are same as I use. mochad-0.1.1x directory shows owned by pi not root. rights for each file and directory set by the installation not me.
tried last night remotely via SSH to install 1.16... not being at pi I could not unplug the cm15 then install then plug back in... when testing with systemctl command it reports there is no mochad.service file. Since I never had THAT error before, I must assume it is because the cm15 must be unplugged until AFTER installation... since I did NOT follow steps exactly I will not judge mochad for this fault - yet.
Re-trying ver 1.16 today...
-
Mike a snapshot from the Sourceforge page. Pay particular attention to the reference to rftopl 0. That command is similar to clearing the CM15 of house codes
By default, received RF X10 commands are repeated on the PL interface for all
house codes. This can be changed using the rftopl command (RF to PL repeater).
rftopl * -- enable all house codes (default)
rftopl abc -- enable for house codes A, B, and C. Disable for all others.
rftopl 0 -- disable for all house codes. This is useful if more than
one CM15A is in use. Leaving both enabled will result in
PL collisions and redundant commands.
Full details here https://sourceforge.net/projects/mochad/files/?source=navbar
-
I have installed Mochad a couple of times via ssh and not unplugged the cm15 on a reboot mochad seen the cm15.
Mochad was originally created to work with RF however I'm not sure it was envisioned to be used with both. Since having the cm15 set to transceive mochad would see the RF signal received as well as the PLC sent which if not coded for would cause lock ups which may be what is happening.
This may be why I never had issue with it as I never used a RF remote (other then a security flob) I only used it for receiving Security RF which there is no PLC equivalent.
I however use PLC remotes extensively in my city residents so a setup requiring mochad will never work for me there.
I'm wondering if other that use X10 remotes and mochad how do they have it setup?
Maybe that is why the other mochad for RF send (can't remember its name) was created. This may be what you need to install for Domoticz if possible. ::)
Having to need an extra x10 program for RF set up a HA program is what turned me away from one of the software possibilities.(also don't remember its name) ::) :'
-
Actually once I got it working I was going to issue rftopl 0 command since I do have my AHP running my other cm15 for daily use until I can get a pi reliable... the only issue this seems to be bring is each command is repeated 2-3 times - NOT my issue.
1.16 ver: I just unplugged cm15 and tried systemctl command on pi: still it errors saying no mochad.service... So rebooted with cm15 unplugged: same not found.
So just issued the install commands on it again wtih cm15 unplugged:
./configure
make
sudo make install
Still missing mochad.service...
And this is on a fresh imaged streatch lite....
-
I have installed Mochad a couple of times via ssh and not unplugged the cm15 on a reboot mochad seen the cm15.
Mochad was originally created to work with RF however I'm not sure it was envisioned to be used with both. Since having the cm15 set to transceive mochad would see the RF signal received as well as the PLC sent which if not coded for would cause lock ups which may be what is happening.
This may be why I never had issue with it as I never used a RF remote (other then a security flob) I only used it for receiving Security RF which there is no PLC equivalent.
I however use PLC remotes extensively in my city residents so a setup requiring mochad will never work for me there.
I'm wondering if other that use X10 remotes and mochad how do they have it setup?
Maybe that is why the other mochad for RF send (can't remember its name) was created. This may be what you need to install for Domoticz if possible. ::)
Having to need an extra x10 program for RF set up a HA program is what turned me away from one of the software possibilities.(also don't remember its name) ::) :'
All good points... tnx for confirmation leaving cm15 plugged in does not break the install.
perhaps the issue is mochad locks up due to receiving too much info too fast? sorta maybe related to the rf comment above...
I think I will go back to ver 1.17 and turn off my other cm15 (ie., rftopl 0) FIRST... that way its duplicate repeat back of mochad command will not happen... see what happens...
btw, THIS cm15 does NOT have repeat/transceiver turned on... but... maybe since the other one on my system DOES, that is equivelant? I also have my XTBR repeating all over the place & my V572RF32 picking up all RF and putting it on the PL... so maybe I need to give mochad a chance with rftopl 0 one time... IF that solves the lock ups, then it proves to me mochad cannot be used in my environment at all. Without my repeats and receivers I could not handle this 1/4 acre 3 separate buildings (including 1 30'x60' STEEL pole barn) that was hard to get x10 sigs into.
the other program is huwey o- domoticz has an install page for it, but my understanding on it was it is cm19 only - ie., serial not usb ? may need to relook before coming over to the dark side & joining your hub...
This may become clear as mud today...
-
tuicemen, thanks again for your info on reserving DCHP IP for certain devices... like broadlink RM2...
I finally bought a router that has this feature and am implementing it.
This IQrouter is a rebranded TPlink unit but with custom code that is said to speed up internet traffic a lot by optimizing stuff; our DSL sometimes has latency of 300msec! This router is said to reduce that by potentially 30x... we will see.
-
I think you'll find the ip reservations will solve the broadlink ip issue it did for both mine.
-
Mike, are you saying you have two CM15s running on the same LAN. Are they running on the same power leg too.
-
Mike it might be worth listing out exactly what X10 hardware and software you are using at the same site. If I'm reading things right now you have two CM15s one hooked up to Pi/Mochad and one hooked up to AHP. On top of this you have a signal amplifier and I assume an X10 security panel broadcasting and receiving signals.
To effectively troubleshoot your Mochad issues you really need to isolate Mochad away from that setup. AHP I imagine will be the dominant in your current setup and it may well be the root of your problem.
My troubleshooting pointers were purely based on Mochad/Pi being the only controller in your setup. I was aware from earlier posts that you had an X10 security panel. Not being an owner or user of one of these panels I assume standard X10 sensors are not interchangeable with security X10 sensors. Again I cannot comment on what effect these could possibly have on your setup.
All I can say is that with Lamp Modules and Appliance Modules Mochad is working fine here.
-
I was going to turn everything else off with the rftopl 0 command at some future point anyway but it seems maybe I need to do that right now so my pi cm15 does not see any of this other activity.
Yes, I blast the line with XTBR putting IIRC 8Vpeak x10sigs on BOTH phases anytime either phase has a sig it can hear. And my V572 antenna is up 30 ft in air and thus cathes all x10 around and puts that on the PL. And my AHP cm15 is very active handling it all 24/7...
I will start fresh again with 1.17 as soon as I get clear of customer troubleshooting phone calls! Dang aerospace customers don't like to wait to get their big machines back running ASAP!
-
I was going to turn everything else off with the rftopl 0 command at some future point anyway but it seems maybe I need to do that right now so my pi cm15 does not see any of this other activity.
Yes, I blast the line with XTBR putting IIRC 8Vpeak x10sigs on BOTH phases anytime either phase has a sig it can hear. And my V572 antenna is up 30 ft in air and thus cathes all x10 around and puts that on the PL. And my AHP cm15 is very active handling it all 24/7...
I will start fresh again with 1.17 as soon as I get clear of customer troubleshooting phone calls! Dang aerospace customers don't like to wait to get their big machines back running ASAP!
Two CM15As and a XTBR, :o I'm surprised you got 3 mins before a lockup.
-
I put 1.17 on new SD with nothing but stretch lite. used normal step by step, installed lib, then mochad. nothing else.
systemctl showed no cm15; plugged in and it found t right away. sent rftopl 0 right away. watched nc 1099 show it go, then next commands i sent go. None of my rf or pl stuff showed up so rftopl did stop them. pretty boring to have it not be able to see any pl activity - not sure what good that is in a HA system., but ok... turned on B house code (rftopl b); it saw a couple b codes I sent. left for 10 minutes, back and it was locked up solid again.
enough. so since it seems to be the only x10 interface for cm15 to domoticz, domoticz is thru here.
I am making a new plain stretch lite image card for next attempts. Guess I will come back to HG and try it - x10 interface seemed solid in it and the kluge habridge was always rock solid - I think it still is running on my main pc.
Does your hub offer a head start image or should I just start with fresh HG download?
-
Just follow Tuicemen original install instructions for HG and the Bridge. The image is being worked on at the moment. When you have HG and the Bridge downloaded you can join in with testing and your suggestions. Everyone will have plenty to do.