Advice wanted--move control of my X10 devices to Hubitat

Hi,

New to Hubitat and love it!

I have several X10 devices that are controlled by scripts running on an rpi. The scripts communicate to a dedicated rpi running a server (mochad, IIRC).

X10 control is done on different rpis using nc, for example:

echo "rf a4 on" | nc -q 2 192.168.0.224 1099

where 192.168.0.224 (port 1099) is the "X10 server". This turns on station a4.

Of course, my code (mostly perl) has maps for user friendly names. I also have code running on an Amazon Alexa server that implements a Smart Home skill that allow my X10 devices to be controlled from Alexa (and also a custom Alexa skill).

I'd like to keep the X10 devices for a while, but eliminate the need to maintain and enhance code running on the rpis. There is also an rpi for an IR server (controls and configures my legacy home entertainment devices). The scripts also interface with Pentair pool automation, a many zone irrigation system (OpenSprinkler) and other stuff.

So, it will be awhile before I get everything migrated, but I figured I'd start with the X10 stuff.

I've read a bit about writing a custom app and driver, and I think I need a driver to implement a new device type?

I think what I want is a type of device that simply does the nc (or open a socket) to the specified ip and port. A string needs to built based on the x10 station being controlled and either the "on" or "off" command. The string would be sent over the socket. X10 only receives, so only a send is needed.

Maybe a preference that associates a device label (Alexa name) with the correct station.

Am I on the right track? Is this the most straight forward approach, given what I already have implemented?

I'm thinking "raw socket" to do the equivalent of the netcat command?

Maybe?

1 Like

Thanks,

I skimmed that post. Seemed like a lot of additional overhead/machinery on the rpi server (eg, CodeRed). I plan to dig in deeper, if required.

But, I'm thinking I could add a few lines of code to an example "basic switch" driver and get what I need. I found an example of a "component switch", but I'm still looking for a stone simple simple switch driver.

Well some of us use Node-RED as the primary rules engine - it's a fantastic way to keep platform agnostic whether you run Hubitat or Home Assistant or many other things (or ALL of them together!). Also helps keep overhead low on the Hubitat itself.

If you are into things Apple the RPi can run HomeBridge which is another great piece of software - exposes all your hubitat devices to Apple HomeKit...

There are many reasons to employ a companion server... :wink:

Ok, seems like I could start with this:

HubitatPublic/examples/drivers/httpGetSwitch.groovy at master · hubitat/HubitatPublic · GitHub

And replace the http gets with sendMessage to a raw socket.

But, I'll have to figure out where to do the connect and close. Do I do it each time and on or off occurs? Or, is there a way to do a connect once? If so, how/when to close?

Where's a good place to get answers to questions like this?

1 Like

This?

https://docs.hubitat.com/index.php?title=Raw_Socket_Interface

https://docs.hubitat.com/index.php?title=Developer_Documentation

Also this forum is correct, change your title though or start a new thread.

1 Like

Thanks--read those too. But, I didn't see an example of using the raw socket interface.

I'll start a new thread on that specifically.

1 Like

Also check the old smartthings developer docs..

1 Like

I've seen several references to SmartThings documentation for HE. I'm ignorant--is there a story behind that?

Are the hubs (or the code running on them) essentially the same?

No, they’re very different. However, they both use the same language (Groovy) for apps and drivers. ST’s sandbox for executing code is in the cloud, while Hubitat’s is local. This similarity arose because Hubitat’s founders were ST users who were dissatisfied with the limitations of cloud based processing.

And ST is moving away from supporting user-developed apps/drivers written in Groovy.

2 Likes

So, I got started on a device driver--was pretty simple.

The first issue I ran into is in testing via a dashboard. Seems the "switch" device template assumes a known device state.

I can never know the state of an X10 switch. It won't report its state and there is no way to know when the switch was pushed manually.

Is there a dashboard template for a switch that has an off button and an on button without presuming a known state?

You could create actions for the on state and off state of the switch that do the same thing, as well as always send an "off" command first so you've placed the device in an assumed known state you can then act on.

Not that I know of, but in programming I sometimes get around that by sending commands that place the device in a known state (like sending OFF), then work from there.

I run this package on a RPi4, works great.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.