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:
So this is a wall switch for a light that has a motion sensor incorporated, and some models are dimmers too.
What drop down capability selectors in my app is this particular one enabled under, and is it in enabled under 'Everything - all capabilities' as well ?
motion sensor ? dimmer ? bulb ? switches ?
Can you just send me a screen grab from HE of the device showing the attributes (and commands)
Right now for capabilities, I just have the everything category selected as I want all HE devices in the broker.
In the MQTT app the devices shows up in:
Switch Devices - MOTION SENSORS and SWITCH
Dimmer Devices - MOTION SENSORS and SWITCH and DIMMERS
I'm using a custom device driver (I wrote), there is a Hubitat in-box one but it has fewer commands (same capabilities though).
SWITCH TYPE:
DIMMER TYPE:
Obviously having a single "onoff" variable for a multi-function device will be problematic, too, as last capability type update will win, so to speak.
So if dimmer is ON, motion detection goes FALSE, ONOFF=FALSE even though the light is still on.
and what capabilities do each of these devices have ?
There is a bug in the 'Everything' selector which is fixed in beta2 - it doesn't populate all the MQTT topics at startup and it does produce an 'unknown'
Here is the conclusion to Stephen's report of the bug...
Sorry, I omitted that. From the drivers:
Switch Type:
capability "Actuator" capability "Motion Sensor" capability "PushableButton" capability "Configuration" capability "Refresh" capability "Sensor" capability "Switch" capability "Light" command "setLightTimeout", [[name:"Light Timeout",type:"ENUM", description:"Time before light turns OFF on no motion - only applies in Occupancy and Vacancy modes.", constraints: ["5 seconds", "1 minute", "5 minutes (default)", "15 minutes", "30 minutes", "disabled"]]] command "Occupancy" command "Vacancy" command "Manual" command "DebugLogging", [[name:"Debug Logging",type:"ENUM", description:"Turn Debug Logging OFF/ON", constraints:["OFF", "ON"]]]
Dimmer Type:
capability "Actuator" capability "Motion Sensor" capability "PushableButton" capability "Configuration" capability "Refresh" capability "Sensor" capability "Switch" capability "Switch Level" capability "Light" command "setDefaultDimmerLevel", [[name:"Default Dimmer Level",type:"NUMBER", description:"Default Dimmer Level Used when Turning ON. (0=Last Dimmer Value)", range: "0..99"]] command "setLightTimeout", [[name:"Light Timeout",type:"ENUM", description:"Time before light turns OFF on no motion - only applies in Occupancy and Vacancy modes.", constraints: ["5 seconds", "1 minute", "5 minutes (default)", "15 minutes", "30 minutes", "disabled"]]] command "Occupancy" command "Vacancy" command "Manual" command "DebugLogging", [[name:"Debug Logging",type:"ENUM", description:"Turn Debug Logging OFF/ON", constraints:["OFF", "ON"]]]
Realistically it might not need both SWITCH and LIGHT capabilities, as those are pretty redundant.
You sure like to make things challenging 
- let me think over what will happen here but I would recommend you don't use 'Everything' currently and enable individual capabilities (see my previous post)
Ah. OK. I'll take a whack at that tomorrow. Need to stop ignoring the family for tonight.
Any chance to get lock codes supported for locks?
