LOL so simple I'm ashamed I didn't even see that setting... Also I have no issues seeing the update when I manually lock and unlock
Thanks Huy that's your 'friendly' name yes ?. Keep the feedback coming it helps everyone.
Kevin
Yep that's my name. So of my devices I've noticed the following:
Valves (open/close) and CO detectors aren't appearing but smoke detectors are.
I have added valves in beta 2 but so far not CO . If I get a chance I'll include those too. I was sort of on an 'on request' path with these less popular devices.
This is an internal HE device yes ?? (not HA)
K
1 Like
All my devices are on HE and I'm wanting to use this to use HA for a frontend
2 Likes
I think a lot of people have the same idea. HE>HA is more complete than the reverse.
Keep us posted here ...
... on your progress and the UI you have chosen in HA (Lovelace or other) and why. I'll try and make it as easy and complete as possible.
1 Like
Curious when will beta2 be released? 
He said mid-February. It isn't quite the exact middle yet. 
Yes it is. It's the 14th, afternoon GMT when humac posted. Feb has 29 days this year, so it's past 14.5 days.
1 Like
29/3=9.7
approx
start to 9.7 beginning
9.7-19.4 middle <<
19.4-29 end
Actually I don't have any big bugs to fix bar my continuing dissatisfaction with page 2 of the app - the 'Virtual devices' and aspects of multiple attribute topics.
beta1 has had a couple of hotfixes and there's some minor bugfixes in beta2 + some extra feature additions and it's a lot faster in reacting to MQTT changes. So I could post a beta2 anytime really but the better I can make it then the more interesting. Probably still a week away.
2 Likes
I was, of course, messing with you.
My install is working pretty well right now. Granted I'm 100% going HE --> Broker, and nothing HA/OpenHAB --> HE.
Jason you'll be happy to know that beta2 drops wildcard subscriptions after discovery instead creating individual subscriptions to enabled devices - to absolutely minimise inward traffic and it also no longer sends non changing values (except status values) out to MQTT.
Although I do run across some devices that have the wrong status in MQTT... Need to find some time to track that down.
I have one door contact sensor, for instance, showing OPEN in the broker and CLOSED in HE.
There is an issue with locks and RGB lights where sometimes status is not being updated on MQTT - although the device state in HE is correct. I thought I introduced this in pre beta2 and have since fixed so it shouldn't happen in the public beta1, nor should it happen with a contact sensor, and usually only shows if you /set a device state from MQTT which you're not doing.
If you have any more info and I can reproduce it then I'll take a look.
I just opened and closed the door, now the status is correct. Not sure how it got off to begin with though. I'll keep my eyes open and see if I can repeat it.
What you could be saying is that at startup of my app it is not sending the correct initial status to MQTT and it's only updated on change .. if that's the case let me know.
Maybe, but maybe not.
I did see that it got a few chattering messages in HE. Maybe the 4 changes in 130ms tripped it up. I've seen the device do that before, I may need to move the magnet.
Here is what I see in HE earlier today - 2 open and 2 close in ~130ms:
dev:252020-02-14 04:55:30.888 pm infoStorage Room Door was closed
dev:252020-02-14 04:55:30.875 pm infoStorage Room Door was closed
dev:252020-02-14 04:55:30.823 pm infoStorage Room Door was opened
dev:252020-02-14 04:55:30.763 pm infoStorage Room Door was opened
The app should be pretty good with things like that as long as HE sends the events in order to my app. The only thing that might cause an issue is that the app knows the existing status and so if the seq went ' closed open closed open' then the app might think the status is 'open' from the 2nd open and if it still thinks that when message 4 'open' arrives it might not update and then message 3 'closed' arrives and posts closed. If you see what I mean.
OK, here is an actual "issue", albeit not a critical one. GE Motion Dimmers and GE Motion Switches are combo devices - they have motion and switch capabilities (and level if it is a dimmer).
It seems the app imports those as motion, then on the switch devices when they turn ON/OFF I get this in the log:
app:18022020-02-14 07:30:20.876 pm errorMQTT: [s] Unknown Category for type switch reported by device Storage Hall Light High
Here is what it looks like in the broker:
Here is the device event that created that log message:
