The main problems I’m facing with Homey are:
- There is no ‘customizable dashboard’ (yet).
- I’d like to create some more advanced flows (with PID controllers, multiple in- & outputs, share (sub-)flows, inject script, etc.), without losing the overview (all in one screen).
- The ease of integrating Homey with other systems, besides installing or writing a custom app.
My way of trying to address these problems (all 3 at once) is the creation of a MQTT Gateway app. Now 2-way communication with Homey becomes available, using the industry standard for IoT messaging: MQTT. This protocol is already implemented by most of the other Home Automation systems.
The first release of the MQTT gateway app (Homey 1.5 & 2.0 support) is already submitted to the app store and currently in review by Athom. NOTE: It’s still experimental!
Personally I’m using the MQTT protocol to communicate with Node RED and I’m creating a dashboard with Node RED Dashboard .
What are your thoughts?
I think this app is a blessing and will solve many current issues regarding flow automation’s. Thus reducing the amount of flows needed for the more complex tasks. And in combination with Virtual Devices it will certainly be an extremely powerful combo. This is exactly what I was looking for!
Harrie you are ons of the best !!
Is your intention to make a sort of live connection from Homey to Node RED? (your number 3)
Tasmota Espurna and the like are using MQTT discovery to ease the connection of devices in Home Assistant. (Domoticz is using this as wel I think)
The devices are automaticly appearing in HA if the devices have this feature enabled.
Yes, that would be a nice one to implement!
The ‘request’ command already covers this partly. Just need to implement the discovery protocol.
Just out of curiosity how does this differ from the current MQTT client/server apps?
This app makes use of the MQTT Client to send en recieve messages.
The client connects to a broker and provides Flow cards.
The Gateway provides an interface for interacting with homey (so you don’t need flow cards):
- Dispatch device state changes for all connected devices.
- Dispatch system info (memory, cpu, etc.) on a regular basis.
- Request info (system, zone, device, capability, etc.).
- Update the state of a device (set capability).
I think I understand. Will be interested to try it.
I currently use the MQTT client to swap information with Domoticz. Domoticz listens to my RTS remotes so homey can keep the cover states in sync. Will be interested to see if this can help.
Nice app! I have made something simular myself but it is not Homey V2 compatible nor available for the public.
I have implemented ‘The Homie Convention’ https://homieiot.github.io which enables you to auto discover your devices and use them for example in OpenHAB with use of their MQTT binding.
This works pretty well for me and enables you to make a dashboard using HabPanel.
Nice! Implementing the Homie convention could be a next step forward.
Therefore we need a mapping between Homey capabilities & Homie properties.
Does this exist already?
Is Homie the ‘default’ implementation for other HAS? Or is it ‘just one of many’ standards?
From what I read about it, it is not the same although nearly equal. (Homie & HA implementation of MQTT discovery)
I have not come across other ‘standards’ of any importance in my last evening search. HA’s MQTT discovery is more widely used in Tasmota/Espurna/Esphomelib/espeasy and that sort of thing.
Does anybody know what the differences are between Homie and HA MQTT discovery?
(PS you just can not have a conversation about this, it reminds me of Airplane (the movie):
You can find some implementations here. It is not very wide spread but I couldn’t find much other standards like Blarp mentioned also.
Mapping the capabilties vs. the properties is not that hard. The standards has some special properties regarding Light/Color control which you need to adept to the correct Homey capabilities. All the other capabilities can easilly be mapped as strings, numbers (float/int) etc.
If I can assist in any way please let me know. I am willing to help. It is in all our interest to have one nice app which opens a lot of possibilities regarding dashboards, mobile apps etc.
The drivers reference contains a list of all capabilities & classes. Maybe that’s a good starting point?
The reference at https://developer.athom.com/docs/apps-reference is probably a better starting point, because you can view the complete definition of each capability there (if you click on the vertical ellipsis on the right).
Openhab has a reading about what they have done:
They too have noticed there are two ‘standards’ Homie and HA MQTT discovery
They have decided to:
“The new MQTT Things extension supports two conventions out-of-the-box” Homie and HA MQTT discovery
“It cannot be stressed enough, to consider changing existing MQTT client devices to an MQTT convention like the mentioned Homie 3.x convention. That might not be possible in some cases though.”
The thing is, there are few that do.
Looks like you need both standards to accomplish a MQTT gateway.
If you want to single out a connection to node red, then maybe homie will be enough.
Hope this helps.
Using lights as an example is it correct that On states are reported as ‘true’ and Off states have blank content in MQTT ?
Sounds like a small bug. I should have a look at it and change the values to be true and false.
I should probably have posted to GitHub too rather than here. Will do so in the future.
This is something I really been missing with Homey so thank you for making this app!
However, I can´t get it to work. Is there something you have to activate somewhere or something else?
I have MQTT and Node-RED running on a RPi connected to Homey via the MQTT Client app, this works great with for example gBridge. But The MQTT Gateway doesn’t seem to connect to it. There is no state changes sent to the server and no commands seems to work so I’m guessing I’m doing something wrong.
I’m using Homey 2.0 and the beta version of you app.