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
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. 
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
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.
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. 
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 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.
It has no inbuilt 'smarts' but it should post a request (/set cmd) to MQTT for the remote thermostat to change it's setpoint - does it not do that ?
Frank, I am not sure why you've split the command and status for the same device into two separate devices but that may mess things up a bit as it checks both internal and MQTT status before deciding if it should send a command to mqtt to change state or indeed triggering an internal event when the mqtt payload updates
Also you seem to have the 'state' information from mqtt 'armed' home-disarmed' in the latter screenshot - does the device take
home/alarm armed as a command ?
In your earlier screenshot you are recovering status to display the state in HE from the
home/alarm/set topic ? You should retrieve the switch_Topic from the mqtt payload showing state and you command a device to change state by publishing to the switch_Cmd topic using e.g. the home/alarm/set topic (or whatever is appropriate for your device) You are using a command topic of homie/alarm
error groovy.lang.MissingMethodException: No signature of method: user_driver_ukusa_Remote_Thermostat_577.setTemperature() is applicable for argument types: (java.lang.Integer) values: [99]
Possible solutions:
setTemperature(java.lang.Object,
java.lang.Object) (setTemperature)
That is error I get when trying to populate the "temperature" variable of the thermostat. This is in the HE device settings using the setTemperature button with a number as a parameter. Note this is not the setpoint but the temperature of the space that would be "sensed" or measured by the thermostat.
I get a similar error when calling the "set Thermostat Mode" command either from a rule or in the device settings page, but I can use the custom action of cool() successfully. See attached error and simplified rule example.
While all three rule actions should give a similar result, only the second actually works.
I should also note that I am not using these to represent devices discovered in MQTT, but as generic virtual thermostats for a different rule. If I'm using this device/ driver for an unintended use, please disregard. The driver is working great for its original purpose of communicating the state of my ecobee via Home Assistant and MQTT.
Download the Hubitat app
