Deleting the two devices and rebooting worked like a charm. I've now got 8 Home Assistant devices detected in the Hubitat app!
I've got two new problems, though. First, my actual ecobee thermostat is not one of them. I'll set that to the side for later. The second problem is that even the devices that were detected don't show their correct states. Take the Ecobee's remote temperature sensor, for example... no temperature value is available.
Also, now that my problems have progressed into the HA portion of the app, I can move to the dedicated MQTT/statestream thread.
I'll PM you Dylan as this may require beta3e as the discovery mechanism via homie or HA Statestream in your case has to autocreate the correct device. There's possibly a few other things I need to go through with you personally to get you up and running. Are HA lights etc working OK for you ?
beta3e will be out shortly - just working on the 'everything' capability dropdown as it has become broken in next beta
Adding ecoBee to HE is not an option due to ‘local’ requirement? Running HA just for ecoBee is quite a commitment.
ecoBee is currently discovered by HE as a virtual thermostat but no attributes are updated? Could you PM me a screenshot of both the fully expanded MQTT broker topics for the thermostat from HA (climate) and also a full screenshot of the virtual thermostat that was auto created in HE
Sending the PM shortly. Actually, getting HA running was pretty painless using my Raspberry Pi, the hass.io image, and bit of help from the community. I'm planning to use the Ecobee and its sensors as the front-end to my HVAC zoning system. I need Home Assistant's local integration (really just hvac_action feedback) with the Ecobee to make sure the zone dampers are triggered reliably. Sending commands to the Ecobee (using the Universal Ecobee Suite App) for setpoint and schedule changes might still be cloud-based, but that seems to work more quickly. A bit of a cobbled together system, but I would rather do it this way than replace my ecobee.
@kevin Is there a way to force a publishing refresh of all measurements to MQTT?
At the moment it seems that I have to wait for a measurement to change before it gets published. This is fine once the receiving client (in my case Indigo) has received the initial values and then the connection is continuous. However, until the initial values are received then it is out-of-sync. This could also occur if there is a break in communication of some sort e.g. updating the HE Hub software.
That would imply that I am publishing the states non retained to the MQTT broker which is not as intended. Let me check but one way to see this is find a topic on MQTT for one of these that originates from HE and then disconnect MQTT Explorer and connect again immediately. If that topic is still listed with a payload then it is correctly published retained and it a problem with the Indigo end
Hi @kevin
I have been making good progress using your MQTT App to interface with Indigo.
One other issue I have come across is with an Aqara dual rocker switch (button) which sends button "pushed", "doubletapped" and "held" to Indigo. After 1 second it sends "idle". That is apart from when it is "held". It seems that the switch doesn't send a "released" message when the button is released.
mqtt.publishMsg (sTopic+'/button/'+"${normalize(type)}","${state}",1,true)
if ((btnNum>=0) && (btnNum < 999)) {
if (type=='held'){
mqtt.publishMsg (sTopic+"/button/button-$btnNum","held",1,true)
pauseExecution(2500)
mqtt.publishMsg (sTopic+"/button/button-$btnNum","idle",1,true)
}
else {
if (type=='pushed' ) mqtt.publishMsg (sTopic+"/button/button-$btnNum","pushed",1,true)
else if (type=='doubleTapped') mqtt.publishMsg (sTopic+"/button/button-$btnNum","doubletapped",1,true)
else if (type=='released') mqtt.publishMsg (sTopic+"/button/button-$btnNum","released",1,true)
pauseExecution(1000)
mqtt.publishMsg (sTopic+"/button/button-$btnNum","idle",1,true)
}
}
else log ("Bad button state $state $btnNum","WARN")
I have chosen an arbitrary time of 2.5 seconds as all I want to detect is the fact that it was held down.
Maybe it is only of use to me but I thought I would mention it as a possibility to have a config option set e.g. if held idle > 0 then delay by the amount of time set in held idle.
Just to confirm that @chirpy has updated the switch driver to allow a release to be configured for a held button. This is now working well with this MQTT App.
I have a virtual switch that was working up until the latest Hubitat system update. The switch does not change state (from off to on) when there is a change in the switch_MAP.
I've noticed that your 'Remote Thermostat' device doesn't respond to the setTemperature command (either when called from a RM action or from the device settings screen). I know this is contrary to your original intent for this device, but I'm trying to set up additional "dumb" thermostats and your driver/device will be ideal. Any chance you could enable this functionality?
What is the home/alarm/set payload and the switch devices state in HE (and the device type) ? Those sort of look like commands rather than states ? (ARM_HOME,DISARM) c.f. ARMED_HOME or DISARMED, bur ARMED HOME would be unusual.