[Beta] MQTT beta 3d (released 5th July)

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.

Yes please... what do I need to do?

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

I have nothing else in HA besides the ecobee and it's remote sensor. None of the states/attributes appear to be updating within HE.

I don't really have anything else to add into HA for testing...

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

image

It looks like some are but the measurements aren't e.g. :

The only reason the measurements (humidity / temp / pressure) are there is because I forced an update by breathing on the device. :slight_smile:

I will double-check my Indigo code as well.

When I connect to the broker and subscribe, these are the initial topics that are received:

Hubitat Warning MSG [20] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/$properties', QOS = '1', Payload = 'measure-humidity,motion,measure-battery,measure-pressure,measure-illuminance,contact,button,presence,acceleration,measure-water,measure-temperature,refresh'
Hubitat Warning MSG [21] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/refresh', QOS = '1', Payload = 'false'
Hubitat Warning MSG [22] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/refresh/$datatype', QOS = '1', Payload = 'boolean'
Hubitat Warning MSG [23] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/refresh/$settable', QOS = '1', Payload = 'true'
Hubitat Warning MSG [24] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/refresh/$name', QOS = '1', Payload = 'Study Temperature-Humidity-Pressure'
Hubitat Warning MSG [25] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/refresh/$retained', QOS = '1', Payload = 'true'
Hubitat Warning MSG [26] - Processing Topic = 'homie/home-1/study-temperature-humidity-pressure/-device-driver', QOS = '1', Payload = 'Xiaomi Aqara Mijia Sensors and Switches'

So it seems to me that the existing measurements aren't being sent?

Is there a step by step install instructions for this? The one on Github doesn't seem to match. I tried setting things up and got nowhere.

Hang on a couple of days and there will be a new beta and I’ll get the install guide updated too

3 Likes

Hi @kevin :slight_smile:
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.

I have posted a question in the [BETA RELEASE] Xiaomi Aqara Mijia Sensors and Switches Driver forum thread but in the meanwhile have got round the problem by modifying the MQTT App as follows:

        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.

Actually, @chirpy has kindly offered to fake a button release in the Aqara device driver which is the better place to do it. :grinning:

1 Like

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.

1 Like

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 am not aware that anything has broken in the MQTT beta 3d app with the latest Hubitat update . You are on 2.2.5.131 ?

Please send me complete screengrab of the device details and the matching MQTT expanded topics and I’ll try here.

(I am aware that MQTT persistent connections are still broken in Hubitat’s current release)

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.