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.
@signal15 curious how this all panned out months later? I happened across this thread while searching for rs485. I have something custom I talk rs485 to via an RPi, currently with just a web interface of its own, via apache->php script that can talk to /dev/ttyUSB0 to obtain and present current status->if change is desired, submit via the same web page with updated settings and it sends them back via serial.
I'm new to HE and was thinking it would be nice to integrate it, but need to figure out the ideal way for HE to poll my local RPi, whether that's MQTT, a rest api I build, "direct" to serial via socat, etc.
I also just learned today that Somfy has a RS232/RS485-based device you can use to integrate up to 16 unique blind/screen/awning installs per device. They have a z-wave gateway but reports are that it's not reliable. I could have the same RPi talk serial to that thing locally to get my blinds integrated without z-wave or taking a long round trip through Somfy's cloud by way of IFTTT.
Polling is not an ideal approach - try and make it real time event driven if possible. i.e. Pi updates HE.
Maker API maybe ??
I use MQTT for all my HA devices wherever possible and it works amazingly well. I am really happy I chose it. The homie spec (mentioned above) is somewhat lacking still though.
My lighting system (wired C-Bus) and my alarm system (Texecom) and my HVAC (evoHome + Tado) all integrate via MQTT. C-Bus handles nearly 200 groups, mixed switch/dim and also provides binary and measurement channels for sensors.
Thanks; will have to dive into the architecture more to come up to speed. I'm not yet at the point where I've read into how HE reflects the state of a device on the dashboard, if it's "known" due to a stored state set via prior event/trigger, or it checks as the dashboard is rendered. Still digging around to figure out what others have already done so I don't reinvent anything. 
I'm going to dive into it this weekend, and since it would all be custom on the other side, if MQTT is the way to go that's where I'll head.
I think Maker API will suit you best.
HE code is architected around event driven state updates. Indeed an app doesn't even run until it get's such an event, but that could be from a timer (for polling)
The dashboard renders the current internal state, it doesn't lookup the state as it renders via say a refresh command.
MQTT would require far more code effort. You could also do something via NodeRED is that's something you're familiar with. NodeRED has nodes available for HE.
I haven't worked on this for months. However, I have a Raspberry Pi with a usb->serial converter on it running mosquitto. And I've created a python daemon that spawns 2 threads, one for MQTT communication and one for serial communication. It basically populates mosquitto with the current status and monitors for commands over mqtt for requested changes. It's almost there, I just need to find an afternoon with some time to finish it. I'll post my code when it's done.
