Ive started out with openHAB2. I was using a Ethernet gateway and tested the mysensors binding but found the combo was too limited. I much prefer having the MQTT gateway and the data be accessible to anything that subscribes, although I also now use openHAB to republish its item changes to MQTT as well which is probably a better approach.
I don't think the main new features in version 2 are very mature at the moment as well, discovered things for example get put in to a non human readable database and the web ui's are not fully functional.
With that being said I'm using node red to provide node ID's and configuring items manually and since beta3 it's been solid as a rock.
thx for reply
yes dragino HE works like yun I think.
for linkit as the product seems new, there is a little bit less docs. but I will see, price was so interesting that it was too much tempting lol.
I will tell you what I can get...
for fun, I have not presented yet, but I have a board in progress for raildin : 8x relays + 8inputs for yun and I added ethernet connector+hub usb chip
Just one final question... is the approach to MQTT correct or should I stick with simple Ethernet? I was planning on using OpenHab or Home Assistant.
Thank You all
I have a project going with openhab and thethingbox. I only use Mqtt with a combination of nrf24l01 and esp8266 modules. thethingbox server is simply used as a catch all for all mqtt messages from sensors or openhab. i parse all the message coming into ththingbox and take action depending on the message. If my door or window sensor is tripped a message is sent to Twitter. I also send temp and humidity readings to thingspeak and my cell phone reports long and lat coordinates to thingspeak so that my lights can come on as I approach the house. My next project is to setup ip cameras and motion sensors and sent pics to drop box.
Openhab is really not hard, you just have to keep at it, once you get it you will kick yourself for over complicating it
Mike
@Michael_K ,
If we go from the front to the back this is what is needed:
1 Node: For example a door bell.
This node sends information to a gateway.
2 The gateway takes the message from the node and sends this to a controller. For instance Openhab or Domotics. This can be done in several ways. MqTT being one.
3 Controller: takes the information and displays it to you.
So in my case, I hardcode Node ID and CHILD ID (the complete door bell is a NODE whereas CHILD IDs may be the button pressed and maybe temperature reading at the same time).
This sends to Gate way that takes the information and creates a MqTT message.
What this message is, please read the instructions on this site.
Perhaps my definition about "controller", is a bit broad here.
What could be done, is to have a thin "controller", that receives MQTT from the existing gateway, hands out IDs if they are requested from a new node, and translate the message into homie compliant topics. That is all it has to do, should not care about the rest of the automation at all. Should also be able to translate back from homie compliant to mysensors.
This could be written in python, c#, javascript, rust etc. The benefit is that you have (relatively) easy editing of configurations at hands, without re-uploading sketches to your gateways / nodes, if you decide that node X should be named Y instead.
And I am in no way trying to treat anyone as a fool!
