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.
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.
Remind me - what is the feature you're awaiting or is not working ?
I have got slightly delayed in adding an additional significant feature that is taking a little while to finish but I could release a version 3e almost immediately if needed
Correct but I am currently working with another Hubitat user who is trying to install MQTT and is having difficulty getting it going with multiple copies of the MQTT app appearing and no broker connection. We are working through your post # details to try and resolve - not there yet..