This is a new utility that is very useful for exploring all topics in use on your broker…
anyone who can help me because I only receive the system status “Homey/unknown/home/system/general/state” ?
I have tried some restarts of the apps and also of Homey itself, but still the same
Do you have some more info?
E.g. What’s your Homey firmware version?
Maybe your’re able to run the app via the athom-cli & grab the debug log?
You already receive the system info from the Gateway app. This means the connection with the broker (via the MQTT Client app) is working.
as already wrote at GitHub:
I don´t know why it was not working before, but after installing the v2.0.1 via athom-cli it works!!!
First impression of HABpanel using MQTT. It’s a working demo, including live updates & setting the values.
All devices and their properties (+datatypes) are automatically detected and imported via the Homie Convention:
I’m on the same path, but with Node Red. In my situation I need to create a flow for every device/state that need to be changed from the Node Red dashboard, might a future update on the MQTT Gateway bring an easy solution for that? Saw a 'FlowTriggerDispatcher: not implemented’message, indicating a flow solution might be implimented at some point.
Thanks so for, happy with the possibilities even without an easy flow solution!
States can be triggered using an ‘update’ message (it’s roughly explained in the app description/readme).
There’s no need to create a flow for device state updates.
Starting flows via a message is not (yet) implemented.
Thanks, I’ll have a look at it!
Just thought I’d let you know I’m following along. Not sure what’s working yet but here’s what I see.
I get my devices discovered , but the connection thing goes offline
Device did not send heartbeat in time
and with control I get a communication error
No connection or readOnly channel!
But looking very promising.
Yes, I noticed Homey is very busy in the startup phase (registering devices) and does sometimes not have enough time to respond to the heartbeat during this period. Restarting the Gateway app, resolves this problem most of the time.
FYI: Currently I’m working on handling color & enum values.
Next: Homey v2.0 & app settings
I have been waiting for something like this!
Looking very promising!
That’s great - it seems there’s an issue with handling the heartbeats/timeouts in OpenHAB - I posted here and there’s a new update coming in a 2.5 nightly.
There might also still be an issue of whitespace inclusion in Homey node topic ID’s still. But it might not be a problem. I have topics with whitespace after the second text e.g. “kitchen-counter near”
PS Do you intend to implement the (alternative much simpler/less capable) HomeAssistant MQTT discovery protocol too - as I think more people on here use that ?
I also noticed the heartbeat timeout is an openHab issue. The dashboard is working correctly even if the Homie MQTT device is stated offline.
Do you want to create GitHub issues for your findings?
HomeAssistant MQTT discovery wasn’t on my radar yet. Could be a nice addition. But let’s first create a ‘stable’ app for both Homey versions. Also a settings page is a must before the app can be published.
Yes, you’re right to get to stable first.
I think a few will later apppreciate HomeAssistant support - and it’s way easier than homie3 .
I’ll raise GitHub issues. I don’t know why whitespace is not supported in the homie3 spec. Not sure how to do GitHub pull requests yet.
I can’t get two way control of devices because I constantly get timeouts and when I control anything I get read only on the set topic, so it is never published from openHAB. I have around 70 devices and the population through homie3 takes around 15 seconds.
Some topicsID’s have that whitespace issue although I quickly patched it out. I think openHAB is assigning defaults, specifically $settable = false to my nodes. They can’t be controlled through Paper UI.
The settable property is read from the Homey device capability.
Yes but it’s then published as a property via MQTT and openHAB assigns default values if it hasn’t received ALL the related node MQTT messages within 1.5 sec (I think) of homie protocol $state ‘init’ - so OH is missing this and defaulting it back to false unfortunately, … but it still shows true in MQTT of course. So OH thinks its not controllable.
I think this 1.5 secs is going to be eliminated in an upcoming OH 2.5 build and await $state ‘ready’ instead.
This is going to be great when it’s ready thanks for the app !
I do not understand how to use this? Can some one help me?
It’s all experimental for now, but roughly follow these steps:
- Install an mqtt broker (Homey app/mosquito/HiveMQ, etc.)
- Install the BETA version of the MQTT Client app & connect to the broker
- Install the MQTT Gateway app from the GitHub ‘homie’ branch via the athom-cli (Homey v1.5.13 only).
- Install OpenHAB or any other application with the ability to communicate over mqtt (HASS, Node RED, mobile app, etc.) & configure the connection with your mqtt broker
- Add a ‘Homie MQTT device’ to your application and let it automatically discover the Homey devices and their capabilities. Or manually configure the MQTT communication channels (see the Homie Convention)
- Build your dashboard