Just a thought - are the devices that don’t respond to an onoff ‘set’ command all currently showing as being in a state where the dim level would then (after the ‘set’) be contradictory to the requested state ?
I’m wondering if it’s the dim level causing the device not to change state. Maybe when off and dim is 0 and you try and set it on Homey still sees the dim is 0 so it leaves it off. Or conversely it’s already on with say dim 0.5 but you try and set it off , Homey sees a dim of 0.5 so leaves it on.
I’ll have a play and see… this might be device dependent.
Ah yes, I see now it’s a power measuring socket in an earlier screenshot you posted. I have both a v1.5 and a v2 - but I haven’t seen this problem on 1.5.
Remind me does it work for some devices and not others or is it consistent across all devices of the socket type. Do you have more than one of these of the same brand and does it work for the others if so ?
There is a log in the MQTT client app too which may be more use here…
You do have the beta version of MQTT client installed (not the release version) ?
You can try enabling the “Enable to provide a custom client ID” checkbox in MQTT Client settings. MQTT brokers don’t like empty or duplicate name clients.
The username / password are set up correctly … (if you use them on your broker)
I tried that also (you never know) but although I entered a client id it keeps on sending the messages under the previous ID (‘homey’). I restarted the apps on Homey, Homey itself and the broker.
@Julian Topic root (default:homie) & device id (default: homey) can be configured from the MQTT Hub app general settings tab. Do you have problems changing those?
The Client ID setting from the MQTT Client probably has no effect on app2app messages (at least it shouldn’t, need to check this).
Furthermore I’m going to test a build in mqtt client. I hope it isn’t needed, but maybe it solves some of the above issues and can result in increased performance (less socket connections).
I think I may have found my problem! I had installed the MQTT Broker for Owntracks and used the userid/pw on my NAS for that also for the Homey MQTT Client. I assumed Homey just needed access to a broker. I started from scratch but made a seperate user id for Homey on my NAS and now it seems to work! Just tested and I was able to make a switch in OpenHAB that controls a light in Homey.
So will do some further testing, it seemed a bit flaky at the beginning but I think that also had to do with the fact that my NAS is quite old so the respons is a bit slow when it is doing other jobs (hmm, good incentive to buy an new one ).
If you enable the inclusion of ‘zone’ or ‘class’ using Homey Hub this will stop Home Assistant discovering your devices using my flow. I hadn’t anticipated that was within the homie3 spec.
As a workaround either disable these or if you do want to include one or both then you will have to edit the ‘everything’ Node to be homie/+/+/+/+/$datatype for one or homie/+/+/+/+/+/$datatype for both. It is homie/+/+/+/$datatype currently.
If you are using specific device matches instead of ‘everything’ then you will need to create a matching topic. Look in MQTT Explorer.
MQTT Hub now allows specific device selection but you still may wish to use the wildcarding + character here instead e.g. to pass specific zones/rooms or specific device classes.
I will work on auto detecting the levels of topic hierarchy that are used.
@scanno Just pushed an update of the MQTT Client (beta) to the store. The app is currently in review by Athom. As soon as its available in the store, you should install it. It will probably fix a lot of connection issues.
It’s no problem … it caught me unawares and it just broke a couple of users too… I think I can auto detect it but other things expecting the homie 3 spec won’t.
Now I know about it I still think it’s a good move to merge the two MQTT topic structures … or maybe create a homie4 spec . V3: has got a few holes.
PS Could MQTT Hub warn that MQTT client isn’t working (old version) or needs updating ?
PPS I have about a dozen beta testers with HA currently… seems good. Prize for the first TileBoard with Homey devices screenshot
This is cool stuff, not really plug and play but worth the effort! Would you recommend OpenHab or HA?
I know HA is getting massive development behind it, but tried both a year ago (and then went to Homey) and found OpenHab a bit more intuitive and easy to use at that time. Now I see HA has LoveLace and more easier ways of making flows, so a bit in the dark on which path to follow.
I have tried both but I’m a mere electronics engineer - not a programmer and I find HA less daunting than OH. The people at OH seem to be heading in a very precise way based on ideology and standards whereas HA seems to be more tolerant of the enthusiast approach. I feel the OH one maybe the right way but not the successful one.
Having said that both seem very stringent on how addons get approved and meeting quality standards, which is comforting. Both are producing great releases.
I like the impetus with HA releases but it seems they are not as stringently tested to be robust, but I can work with that. They are usually fixed within a day or so. I also feel I can ask questions in the HA forums and bar a few ‘characters’ you can expect to get a helpful response. With OH I expect to be belittled , or provided with only sparse information.
So I’m quite happy with HA at the moment and the recent visual developments for the UI options are great. It’s doing what I need (mostly) . OH has some ambitious plans to address the UI too with a replacement to Paper UI but they seem to be the trailing runners in this.
OH have also just announced they are merging their commercial offshoot (the ‘open standard’ Eclipse commercial project foundation) back into the OH umbrella - which I think is a good move for the future but to me indicates they can’t get long term commercial developer commitment to Eclipse . Deutsche Telecom are pulling out it seems.
So I’m passingly with both but focussing at the moment on Home Assistant.
(BTW I also like HomeSeer.)
btw just throwing this out here to show the value of this app:
thanks to the MQTT Hub, the OpenHAB integration and the myopenhab cloud connector i made my lights directly controllable via google home so no more "ok google, tell/ask homey to… "
of course with a couple seconds delay since it goes from google mini, to google cloud, to openhab cloud, to local openhab, to homey, to lights
That’s great … and Phuturist did it with HomeAssistant - it’s a shame we have to leverage these other apps for better Google Home integration but there you go… at least you have choices and better UI options now - that don’t force you to use a tiny phone screen.
).
V3: has got a few holes.
so no more "ok google, tell/ask homey to… "
