Software architecture question for device that interfaces the HE to a lighting controller

I built a plugin for Vera to interface with my LiteTouch controller. Because the LiteTouch doesn't support unsolicited updates (like when someone changes a light from the wall switch) and also doesn't have a command that returns the status of all lights, I have this FIFO polling queue that runs in a loop. It has to run with a delay between polling each device, or the controller gets confused and sends back results out of order. I've been told that I should NOT implement this on the HE because it will put considerable load on it.

So, I'm going to hook up a Raspberry Pi via serial port to the litetouch controller and do my polling loop there. I was looking at Flask/Celery to do this where flask would launch the polling process via celery, and then Flask would provide a REST API that I could use to integrate with the HE. A couple of problems with this:

  1. It didn't seem immediately obvious to me what would happen if something else hit the REST API. Would it try to launch another polling task in celery?
  2. With a REST API, I don't think it's possible to send unsolicited updates back to the HE, which means the HE still needs to do some level of polling which I would like to avoid.

Should I just write a python daemon that dumps the results into Redis, and then my Groovy app on HE will spawn a connection to Redis directly? It seems that I may be able to facilitate unsolicited updates this way using the LUA scripting engine in Redis. Flask still might be a nice to have so I can have a web interface on the Pi to directly configure load names or create virtual groups, but not necessary. Since celery is just a daemon that gets python code pushed to it, and it works over the network, can I start a celery task with Groovy somehow? Just throwing out some options.

The goal now is just to get it integrated in a way that I can extend it without making a bunch of design changes.

Here's a diagram of what I'm looking to do:

Here's the Vera code I wrote that does the serial integration to the LiteTouch if anyone wants to look at it:

The polling queue stuff is actually a little more complex than I described above because I also have a Priority Queue which is used to immediately poll a device after a command has been sent to it to verify that it actually changed.

Any thoughts on the best way to do this, keep in mind that I would REALLY like HE to be able to receive unsolicited updates from whatever I do on the Pi.

Ooooh, another option is to put NodeRed on the Pi, and use the serial port plugin.

Crickets!

The more I look at this, the more I think a python daemon interfacing with the lighting system over serial, and storing data in redis is the way to go.

So, the question now is... Can I load a redis client library for Groovy on the HE? This way I can make a native redis connection and use the pub/sub stuff to issue changes and receive unsolicited updates.

No. You cannot add anything to the platform. Only Hubitat can do that. And based on the response from your first post, I doubt that is going to happen.

Personally, I don't understand why you are trying to interface that platform with Hubitat in the first place. It is a system unto itself that doesn't seem like it wants to integrate with other systems.

It controls all of my lights. Why wouldn't I want it connected to my Hubitat?

Yeah, it's ancient, but I don't wanna spend $50k to replace it. I can't just put in regular dimmers in the wall, because all lights are wired back to the basement. Frankly, it's a pretty awesome system, even considering that it is 25 years old.

I have a newer controller that has a serial protocol that supports unsolicited updates and group status queries. But I get an error when trying to push the programming to it, I don't think the programming software likes usb to serial converters.

I think the bigger question is...why Hubitat?

That’s pretty intense

Well, aren't all your lights connected back to your breaker panel?

And that's how these hard-wired systems like this one and Control4 work. That's why they're so expensive and why they are so reliable. No wireless.

Not as home runs.. Usually have many things on a breaker.. Something like this must have been a monumental job..

Although it has a serial interface.. Seems like it would be a fun programming project to integrate

Yeah...it is. Profesionally installed systems don't rely on wall dimmers...they use button controllers and all the lights are controlled from a central location. Take a look at Lutrons RadioRA systems. Or control4. That's the only way to do it. And those systems are usually put in when the house is built. And even then they are many tens of thousands of dollars to install...sometimes more depending on the size of the system. But they integrate home audio and video as well as lighting and shades, etc. There's a reason those systems are so expensive.

This one was installed during a major remodel in 1995. It cost $45k... In 1995 dollars. Mine is a small setup also. I only have 48 lighting loads on it. The other controller I have came out of a 45,000 sq ft mansion with over 1100 lighting loads.

As for it being a fun project... It is. I already wrote the plugin for it to integrate with Vera and I've been using it for 6 years. But because the HE doesn't have the ability to directly connect via serial like the Vera does, I need to figure out the best way to architect a solution.

1 Like

Just a guess while reading your post.
I see serial, I think RS485 or RS232.
I think RS232, I think now to node-red, then mqtt (yeah, I know, I learn).
tagging @Ryan780, is it possible to build that link to Hubitat ?

I'm not sure I understand your question. Is it possible to link an RS232 device to Hubitat? Yes, you can. But it's not going to be easy. If he already has an interface to Vera built then building another to Hubitat shouldn't be a problem. The issue is going to become the frequency of the polling. How often are you going to poll that setup to detect local changes? I can see traffic becoming an issue there.

Will it though?.. Z-wave is max at 100kbps.. Rs232 can go higher... It just depends on how efficient the protocol is.

You could even go direct with a serial to ethernet adaptor and use the telnet functionality of HE..

I have done some modbus programming (over rs485) for industrial automation... This would be a fun project...

If you can implement a telnet server on the pi, then on the Hubitat side all you need is a device that implements the telnet client we have, that's one way to do it without polling on the Hubitat side.

I meant the amount of traffic for all the polling between node red and the hub. I don't care about the 232 connection.

As you "know", I have a lot of modbus devices at home and I really want to access them with my HE. reading this post leads to another question:

is it easier to poll modbus devices using modbus/node-red/mqtt/HE OR using modbus/HE trough TTL ?
I mean, I'm no developer and sometimes using built-in tools, even not the best solution, is globally easier than developping a custom (faster) solution (driver/app/etc).

your opinion on this ?

How about Konnected interface module? Possible you can skip all this integration and directly connect the interface module to you system.
I could be 100% wrong but it's worth looking at.