SmartThings Community

[UPDATED] Node Red Bridge for X-10 Devices (Switches, Modules, Remotes, Sensors and Security Modules)


(phil) #121

Nope I think I am good. I still seem to get double messages sent. But as long as it works I am happy and it has been working VERY well. Most of all it saved me a lot of money by not having to go out and buy more zwave devices

(Denis Grabocka) #122

Ok so i was using CM15Pro/A with the old method —> Raspberry pi Ubuntu-Mate image > Mochad > Stausbits device handler and smart app… for over a year and it was working flawlessly until last week (well i guess 2 weeks now) whenever SmartThings updated their hub… At least that’s when i realized that it wasn’t working, i might have also done an sudo apt-get update/upgrade on the RPi as well around the same time so i am not for sure what exactly caoused it but one of those two sure did.
Either way it stopped working and it seemed like the part between ST issuing commands and the mochad not getting it was the part not working, beacuse ST or Alexa though ST thinks that is working fine and replaying with OK and if i went on the Rpi terminal and send “echo “pl a1 on” | nc localhost 1099” or off commands it will work meaning the mochad would work by itself also, just not in conjuction as they did before.
I took that sd card out and popped in another one that already had a Rasbian Stretch image which is also running another server on it so i wanted to use that card and Rpi for a dual purpose. I tried to download mochad so i could load Node and try your version of x10 control but i could not get it to work properly.

It will only turn things OFF but not ON and if you try to restart mochad it will say that the CM15 was not found … i have removed the cm15 and hooked it up to ActiveHomePro on my windows pc and reset it and there it works flawlessly on and off just fine but the problem remains on Rpi. What do you think is the cause???

The oddest thing happened afterwards i put the first sd card with the Ubuntu Mate image in (being out for a few days) and it started working again just fine until i did another update/upgrade and it quit working again.

I tried trouble shooting and reading the net for anything that will help my case but i am stuck with no working images of Mochad anyone has any idea what is going on and where to start with the troubleshooting… was it maybe a network glitch at first??

I know i should post this on a mochad community board as well but i thought i would start here first.

In the mean time I am thinking about getting a fresh Rasbian image and start fresh from the beginning tonight the only thing about that is that i also have to built my alarmserver server and xrdp again from scratch


(Enis Hoca) #123

You got a lot of info there a whole novella :smile: so kinda hard to parse what is working what isn’t

What i gather is that your present state is that

  1. your statusbits DH is not working with nc - not familiar with statusbits DH (at-least don’t remember it)
  2. nc works for off but not on.
  3. restarting mochad gives you an error.

I don’t think I can help you with 1 -

For 2 - do this - if you have an RF receiver - send out RF commands instead of PL commands i.e RF A1 On etc
see if that works - if that works time to replace CM15 or be content using it with RF. I had a CM15 flake out on me like that - its a shame that you will have to do with an $80 device what a $20 device can do, but hey better than spending another 80 on old tect

For 3 - it could also be that your previous instance has simply not release the device from the USB not knowing your setup its kinda hard to guess. If mochad runs after a clean reboot then you should be good and don’t worry about it too much, if not could be a problem with CM15

Or it could all be a messed up pi installation - If I were you I would first make a new image on a new SD card, install libusb and copy the mochad binary from the old system on it and see if that works. if it does then you know that your HW is good - if it doesn’t ditch the HW and then start troubleshooting.

(Denis Grabocka) #124

@enis LOL yeap i sure wrote a novella there :slight_smile:
I did because i was perplexed… the CM15 did not go out immediately, it quit than it worked again than no longer over PL… but i guess i solved it you are right it was a faulty CM15.
I have 2 of them the first one did not work from the beginning the second one worked nicely for a year i also have a CM19 and that works too and that is what i am using now to save an outlet since no more PL is possible.
I liked however the power line interface better than RF but i am not going to spend $80 for the old x10.

I have an idea though, a sort of request actually, if possible…if you remember we have exchanged comments regarding UPB modules before… i have a couple of UPB wall switches already installed in very important places that work very nicely but i can no longer control them now through home automation having switched to SmartThings rendering them dumb. I also have a usb power line interface and a plug-in module … so i was thinking if i could ship them to you (with a return postage also) and you can take your time, whenever you find some, and have a look at it and see if you could make it work either with the above node method or any for that matter.
No time pressure no nothing and i am sure there are others that have upb devices and would appreciate it just as much i will.
I don’t have the technical expertise to pull something like this by myself but i have a feeling it should be easier for you.
Let me know if you want to take a shot at it and pm me. It will mean a lot to me if i can get them to work

Thank you

(Enis Hoca) #125

I kinda feel the same way - plus the added benefit of RF in a house like mine is that I don’t have to worry about phase jumping. Plus most of the good stuff that is relevant for me is RF anyway sensors, remotes.

Bad timing my friend - my contract is ending and have to look for new work. Don’t know how long it would take so have to keep focus. So once I am either employed or unemployed I can take a look. These days I have to do my day job and look for work.

However if you want we could take a crack at doing this over PM - just like I did they heyu implementation without ever seeing a heyu. The basic architecture of my node-red code is fairly straight forward. So if UPB has a command line or TCP interface and depending on what you are thinking about doing, it may not be that hard.


Enis, Thanks for the amazing work you have done. I’ve bee using Mochad–> HABridge–>ST/Alexa on a Raspberry Pi and was excited to see this post because dimming was not working for me under HABridge. I disabled HABridge and was able to get this working following your detailed instructions.

  1. Noticed that the ST devices appear under the IDE as “Cloud” execution location. Is this right? HABridge used to say local. Your notes state everything runs locally. Can you please confirm?
  2. I have an X10 chime and some x10 outlets. Is there a way to disable the dimming function in ST for these devices?


(Enis Hoca) #127

1- it’s semantics and context - there are a couple of X-10 solutions in the forum that require setting up OAuth and/or external connectivity and opening incoming ports. So local was in that context not in ST local control context

2- Too much work for too little gain - if you are handy with coding - you are welcome to customize the DH. Dimmer functions should have no effect on those devices - just like dimming them using an X-10 remote. Infact the software behaves exactly like an X-10 remote does


I am not a developer but will look through DH code and see if I can make changes. I have an outlet controlled by a dimmer x10 light switch where I don’t want dimming to be an option. Thanks.

(Blake M.) #129

Hey All - Hoping you can help. I have everything setup but when I flip any switch in the Smartthings app I get an error message in the debug screen node-RED on the mochad tcp node that reads “TypeError: Invalid data, chunk must be a string or buffer, not object”

from the looks of it the parse send message node is outputting a string string [10] “RF E1 off↵”
Any ideas?


I have this situation. Running cast-web-api device handler on the same linux box as my node-red/mochad setup. What is the solution to this? If I change the cast-web-api’s network id in smartthings device, it stops working. Is it possible to run the Node Red Bridge on the same server as other Smartthings bridges?

(Enis Hoca) #131

No idea - sorry try the Node Red forum - could be a Node-Red version thing, don’t know what version they are on now

(Enis Hoca) #132

It’s smartthings limitation - only solution I know of is get another device I have 3-4 Raspberry pi zero w’s I use, they are only $5.00 plus a microsd and a micro-usb charger

(Blake M.) #133

Interesting I wrote an update yesterday but it never submitted it lol

I wanted to update as I have done some more troubleshooting - its working “sort of” (in a hacky band-aid sort of way)

I discovered that I was able to send 1 command when mochad would first start, but any more commands after that would fail with the “TypeError” message above. If I unplugged the CM15A from the pi and plugged it back in (basically restarting the mochad service and killing any connections to it) I could send 1 more command (and again any after that would fail).

I first changed the tcp request node return property to “immediately - don’t wait for a reply” which then made all the commands sent from smart things to mochad work, however if you used a x10 remote to turn off the module smart things would become out of sync due to the connection being closed.

So in a hacky attempt to fix I added another tcp request node and connected it to the Rate Limiter (but not receiving input from the “/push” node). This node is connected to same localhost 1099 but the return property is set to “never - keep connection open”. This seems to have resolved the sync issue as it is able to relay the x10 commands back to smartthings.

Being a noob to node-red and mochad I’m sure that I have overlooked something in the original flow, or have done something wrong to cause this, or my noob hacky fix will undoubtedly cause me some other headache down the road (LOL) so any advice/guidance is appreciated!

(Enis Hoca) #134

Don’t know why you are having the original problem - what are you running this on? There is echo suppression issue inherent in this solution that is related to timing its worked for most people but in your case its acting up.

Can you upload your flow here or as a git gist - Actually doing a second listener on 1099 is brilliant as long as you don’t listen when you are sending out the command yourself, and having a secondary listener it may make it easier to control as you have done.

(Blake M.) #135

This is running on a Raspberry Pi 3 Model B running Raspbian Stretch (9.4)

I am running version 0.1.17 of MOCHAD (due to the fact that there were changes in the recent versions of Raspbian that changed how background services are managed. .17 fixed the issue I had that MOCHAD wasn’t starting when ever the CM15A was plugged in. I did try reverting back to .16 to see if that was the issue but it made no difference)

Node-RED is version 0.19.1

So far the 2 listeners seem to be working well - below is the flow I am currently running:

(Dan G) #136

I think I am getting close…

Step 3 of the instructions states to install all 5 SmartApps. In the Git repository there are only 4 SmartApps. If I copy the SmartApp codes from above for the 5 SmartApps, I receive an error message when I try to create the last one - No signature of method error. Therefore, I installed the 4 SmartApps from GitHub and then I install the SmartApp on my phone, setting IP/port. I then try to add an X-10 device. When I select “Save” to add the X-10 device, the SmartThings app (both versions: the Classic and the new one) run for a moment and then come back with “An unexpected error occured”.

Any idea what may be causing this error? Is it related to me installing only 4 out of the 5 SmartApps? If so, where do I find a working version of the “missing” SmartApp?

Could you please let me know what are the next steps to integrate with my Google Home?

Thank you!

(Enis Hoca) #137

That is because the last one is not a SmartApp its Device Type Handler. Instructions say that

You need to create a Device Hanlder - the code is in github the link here points to it

(Dan G) #138

Hello Enis - Thank you for the help! I created the DTH and I can now add an X10 device without error.

I added this new X10 device to ST - the ST web app shows this device connected to the ST hub. In the iOS ST app, I tap “Automation” -> Google -> Switches -> Select this X10 device. Now I can ask Google (Hey Google) to turn this X10 device X10 light switch) on or off and Google confirms turning on/off, but the light does not turn on/off. Other non-X10 lights work fine.

I edit the X10 device in the ST web app and I see the Type * is set to “X-10 Node Red Device”. I also can SSH into the Pi and use the nc commend to turn this X10 device on/off - so this is working. Any ideas or help is greatly appreciated.

Thank you!

(Dan G) #139

More info - I look at Live Logging in ST and I see the following error message under F-8 Dan Light where Dan Light is the X10 device at F8:

java.lang.NullPointerException: Cannot invoke method toInteger() on null object @line 179 (setDeviceStatus)

Looks like the error occurs here in “X-10 Node Red Switch Child”:
def setDeviceStatus(deviceString, status) {
log.debug “Child setDeviceStatus deviceString:[${deviceString}] state.deviceString:[${state.deviceString}]”
def theDevice = getDevicebyNetworkId(getX10DeviceID())
if ((theDevice) && (deviceString= state.deviceString)) { // The switch already exists
int level = theDevice.currentValue(“level”).toInteger() <<<< this is line 179 - ERROR
switch (status) {
case “on”:
//log.trace (“Turning on”)

(Enis Hoca) #140

can you turn the device on/off from the ST app? try if that works, if not delete everything in Smartthings app/web gui and start over. Looks like the device wasn’t created properly, hard to say why that would be but that what it seems like. May be side-effect of what you were doing before.