@HarriedeGroot great work! Really appreciated!
Submitted to store (beta), waiting for approval:
Version 2.2.3
- Flowcard Triggers & Actions
- Improved performance of Homie discovery devices list
Version 2.2.2
- Updated app icons & images
- Fixed a small styling issue in MQTT Device capabilities list
3 Likes
Version 2.2.3 is available on the beta channel now.
beta 2.2.3 - Managed to add individual MQTT devices but I can’t get the discovery to work.
First time it did keep adding blank lines about 1 every 5 secs, under what I think will become a device list but it never completed and after 10 mins I backed out. I have around 30 discoverable devices from my other Homey under a different device tree.
Next and subsequent times it wouldn’t do anything - just a spinning circle. I don’t think it was accessing the MQTT broker to read anything from the homie topic.
K
No I hadn’t actually - they are retained topics … but of course there would have been a session in place so the info might not arrive when needed. I did try restarting the Hub app. I’ll give ‘broadcast’ a go from the other Homey.
I know the messages are retained on the broker. But the MQTT Client doesn’t return the retained messages when (re)subscribing to a topic. That’s something I need to have a chat about with @scanno.
Yep - understand - it might need the whole connection taking down and re-establishing. I see if your broadcast suggestion works.
Update: Yes that works - it takes a little while to populate but it gets there.
Could a re-trigger broadcast somehow be setup in a similar way as to the homeassistant LWT - as a workaround ? It would have to somehow work with different device trees (hubs) within the homie topic hierarchy - a way to force an individual one to resend…
Retained messages should be working on the client. Or they are not passed through the App2app interface?
@HarriedeGroot - how does the Hub decide it has retrieved all the topics from a Homie branch when discovering, is it timeout based ? Sometimes that phase seems to end but I only have about 5 devices returned when there are a lot more. I suspect this maybe the delay in the other Hub repopulating.
(Just for completeness I’m not clicking ‘broadcast’ but having to restart the other hub as it’s on 1.5.13)
K
it uses the /$nodes to get the available nodes (homey devices). Loading stops when all nodes are discovered.
Well that’s very sensible… need to investigate further…
Awesome stuff. Ran into something though. I just tried to add a MQTT device but I can only seem to find a Turned On capability but not a Turned Off capability. Am I missing something?
Submitted to store (beta channel; waiting for approval)
Version 2.2.4
- Manage topics after the device is installed (device
advanced settingsmenu) - Added
percentage scalingdevice setting - Fixed a bug in the device manager when adding or removing Homey devices
- Increased max log lines to 1000 for debug level
NOTE: Managing topics afterwards will only work for newly added devices.
@Phuturist Turned on is also the turned off capability.
You need to provide a payload false to turn off the device.
Roger that, quite obvious. It’s time to go to bed.
My device actually has a ‘on’ and ‘off’ payload instead of true or false for its onoff capability. Any way to deal with this?
@Phuturist ‘on’ is also recognized as true 
All these payloads (case insensitive) will turn ON the device: true | ‘true’ | 1 | ‘1’ | ‘on’ | ‘yes’
All others turn OFF.
After adding the device and switching the device within the Homey app it sets the topic with true or false. The actual device does not respond to that as it’s expecting a ‘on’ or ‘off’ paypload.
