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.
Modbus is super easy to program for.. For me I would try to go the direct route of programming it in HE .. But that’s my preference .. Fewer devices in the middle
in HE (driver/app) or other kind of programing ?
What I've done so far:
I could install an MQTT broker on the pi and update it with the polling daemon. And then send commands via MQTT to the pi from the HE.
That might be a good alternative to Redis. Although, redis is being used more and more directly for iot devices.
that's @kevin is implementing with his alpha/beta release of mqtt app for HE
And what about this kind of device ( @bcopeland) ?
I’ve used these to get rs-485 to IP
From there you can use telnet functionality in HE
Seems me like it would be cheaper and more flexible to use a Raspberry pi with a usb->serial converter, and then fire up socat to provide the ip connectivity. I've used this frequently for rs232, but There's no reason it wouldn't work with an rs485 dongle.
OK, I think I have figured out what I am going to do. On the LiteTouch side, I have connected it to a Pi3 via serial. I've installed mosquitto. I will write a python daemon that does the polling and stores the results as a dict. When I write the HE driver, it can query for status when it first starts up, and receive the dict contents.
Both the HE and the python daemon will be publishers and subscribers to topic(s). When something changes on the LiteTouch, an update will be sent to the HE. When the HE makes a change to a load, the python daemon will put it into the command queue.
I just need to figure out if I should do a single topic for the LiteTouch controller, or multiple topics which would be one for each load.
I already have a python script talking to the controller which can query loads and set loads. Just need to implement polling and MQTT in it.
To me this would look like the best choice too. Keep in mind that there are already MQTT drivers for HE, so you might not need to write your own for this.
Do you have links? I only saw a client that you could use to write your own drivers.
I use this to publish and subscribe to a couple of topics. I've copied the driver and edited it for personal use to give it different capabilities with in HE for my use (presence for instance)
Just to throw another option out there if you haven't already considered it, check out openLUUP - this will likely run your Vera code as-is (on a Pi, linux box, windows box, Docker, etc).
openLUUP provides all the same REST type interfaces as Vera does, so it's pretty easy to integrate to HE from there. There's an MQTT bi-directional plugin for Vera, which will also run under openLUUP.
Might save you some time as it would mostly just be pulling some pieces together, as opposed to creating something from scratch.
That's not a bad idea. I've looked at Openluup before.
Man, if there was an HE app to connect to Vera and import all/selected devices, one could take advantage of all the Vera drivers by just using Openluup on a Pi.
There sort of is, although it involves several pieces - with your plugin under openLUUP you could also install the MQTT plugin there too, which should give you bi-directional communication for all the devices (from memory you just have to check mark against all devices you want to expose to the MQTT bus).
Then on HE, there's an Alpha (nearing Beta) MQTT app, I know that does automatic discovery and device creation for Home Assistant and a few others, not sure about Vera devices though, but probably wouldn't be a huge task to create them manually.
Are you talking about this one? MQTT Client - Beta
Because if so, this doesn't look like it's an App in the HE sense... It's just the functions for MQTT that you can use when writing a driver.
If there is another app that does discovery and such, then I'll use that and make sure my topic structure and commands/functions support whatever it does for discovery and device creation.
That's perfect! I was looking at using the Homie mqtt schema anyway.
