Oh, yes. Thats right. Sorry for misunderstanding. But your app is also sending updates back to the MQTT to control each switch on the pool, so it is working both ways except for the Temperature measurements.
Once it stops updating though I believe I can still control the switches using your app but if I control the switch from the pool its status doesn't update in your app.
So it works like this for three days: MQTT <-> HE, then goes to this MQTT <- HE.
I've done a little more testing. Loosing connect to the Raspberry Pi is what starts the problems. When I reset the Pi your app seems to reconnect after boot up but no longer updates the devices in HE. Your app is able to sent control commands back to the broker but updates from the broker don't update on the HE.
Here is what the log looks like after I click Done in the MQTT app.
Here is what the logs show after restarting the Pi.
Looks like it reconnects but doesn't resubscribe to all the devices?
@kevin I've been running the app for about a week now and it's working like a champ. Thanks again for taking the insane amount of time out of your own life to help a new guy along. It won't go forgotten.
I look forward to what you have coming down the pipe, man! Thanks again for what you do here.
I have posted the latest hotfix version beta 3d, hopefully there will just be one more beta 3e hotfix and then a release version. There wont be a beta 4.
Briefly changes are :
supports a 'ramp' command from MQTT to set the level of a dim device over a period of time
supports exposure of the 'refresh' command from devices that implement it
virtual WindowShades support and HA integration
virtual Covers support / bugfix and HA integration
json fixes and improvements
supports json payload in _Cmd topics
topic1/topic2/topic3{key:}
supports additional (fixed) json keys in _Cmd topic
topic1/topic2/topic3{key:}{key2:3,key3:"whatever"}
json incoming updates now work in all permutations (to multiple devices each with multiple attributes)
_MAP attribute handling improvements and bug fixes
_MAP values now support differing payload values for incoming state and outgoing commands e.g. 'close' and 'closed', 'on' and 'On' [on,off][On,Off] the (optional) latter pair are for theoutotgoing command sent to MQTT.
virtual editor now restricted to app created devices only - (excludes HE created devices)
virtual Button support from MQTT removed
various bug fixes
Known issues:
homie incoming discovery incomplete
_MAP attributes only implemented for some device / attribute types
Child client device creation (hang on install fixed but still might require 'delete & re-run' workaround)
Documentation outdated still
Others ?? Please remind me / let me know
I noticed after upgrading I was having issues. The device handler Import URL still had https://raw.githubusercontent.com/xAPPO/MQTT/beta/MQTT%20Client%20driver as the URL, but going to your github for your new code I see it should be beta3.
https://raw.githubusercontent.com/xAPPO/MQTT/beta3/MQTT%20Client%20driver
That might have been an issue on my end. But wanted to post in case anyone else had a similar issue not being able to connect to their MQTT broker.
now fixed in posted version... thanks
I'm looking to use Hubitat to control my Ecobee thermostat which is added to Home Assistant using homekit. This gives me local control of the thermostat. Will this app accomplish this? I realize that thermostats aren't natively supported yet but can I use a virtual device to accomplish this? I'm struggling a bit with understanding how to create the mappings and don't want to waste more time if this simply doesn't work.
I'm a bit confused. If you have the ecobee in Home Assistant and homekit - isn't that local control already? Or do you mean control it from Hubitat rules/apps ? Or Both ?!?!
if it's just hubitat there is an Ecobee integration that might work.
If @kevin not done with thermostats then you'd have to wait. Virtual Thermostat won't help.
Ecobees always use the cloud to communicate with the thermostats unless you're using Homekit. I'm using Home Assistant to connect my Ecobees as Homekit devices but all of my logic is in Hubitat. I need to be able to 'mirror' the device in Hubitat so that the actual commands are being sent from Homekit.
The reason this is important is that I'm in an area with peak electrical billing hours and peak demand charges based upon highest hourly consumption. To help with this, I use an app for Hubitat called Demand Manager to stop the air conditioners when my power consumption gets too high for that hour. When the Ecobee cloud servers go down, and they go down often, I lose the ability to shut off the air conditioners and if I'm not around to notice, it adds many hundreds of dollars to my bill.
It's also important when I'm logging the state of the thermostats. Refreshing them creates an api request to Ecobee's cloud servers and I'm worried that they'll rate limit me if I do this too often. I want to poll often so I know exactly when my HVAC starts and stops.
Long story short, I need local control of the Ecobee thermostats and the only way to do it currently is with Homekit.
So this is a device on HomeAssistant that originates from it's HomeKit integration ? You want to be able to control it locally ? Can't you already do that from HomeAssistant ?
Or you publish some virtual devices (switch temperature etc) from HE over to HomeAssistant and then link these to control the thermostat in HA allowing the rules to run in HE.
Or you could link the thermostat to HE but that will be cloud integration.
Or you could like at the possibility of using the HomeKit integration with HE but I don't use that so I don't know if that's possible. You could try a 'Can I control a HomeKit thermostat from HE ' topic.
Thermostat integration via MQTT is awkward , especially using the HE inbuilt virtual device. Both impose 'smarts' I know you can turn some automation aspects off in the HE virtual device but I suspect that I would end up with both thermostats competing and so I have not implemented it into HE. From HE a thermostat is published correctly to MQTT and HA though.
Now there is nothing to stop you taking the topics that HA publishes for the thermostat from HA via MQTT and importing those into separate ad hoc devices in HE (a switch sensor etc) - and then issuing the correct commands back to HA from HE via MQTT to control it . That will take a bit of work but you can do that and it will work. You likely only have to implement a few of the topics.
Do you mean that - so HA can't send commands using it's device representation ? Or you mean from HA to HomeKit to the device ?
I can help with that if you tell me what the MQTT payload(s) are and what virtual device(s) and attribute(s) you are trying to map to.
You could very easily expose that'shutdown request' as a simple switch on MQTT and then onward to HA and then use that to trigger an action in HA that turns off the AC ???
Rather than trying to mirror the thermostat to HE
I can control it locally using Home Assistant->Homekit, but my logic is all on Hubitat and I'd like to keep it that way since my HVAC automations are pretty extensive.
AFAIK the Homekit integrations in Hubitat, like the Homebridge ones, only allow you to control Hubitat devices with the Home app. I need something that works in the opposite direction, which is why I'm using HA since it allows you to pair and control Homekit devices locally. Now I just need a way to access those thermostats from HE.
Dang. I need something that does exactly the opposite of that.
I'll look into this. I've spent a while trying to do it the other way with virtual devices created in HE and reading the fields on the HA side but your way is probably better. I'll give that a go now that I understand better how MQTT works.
HA and Hubitat can control the Ecobees, but unless you're using Homekit to communicate with them, everything goes through the Ecobee cloud servers and those servers go offline quite frequently. This is a huge problem in my case since HA or HE has no ability to shut off the air conditioners when their cloud services are offline.
Looking back, I should have used simple zwave thermostats but I need 4 and the Ecobees weren't cheap so I'm kind of stuck with them now.
Thanks for the pointers. I'll see if I can get something working here soon.
That's exactly what I've been working on and I'm almost finished. It's pretty clunky though. I'm using your MQTT integration with HE's virtual rgb lights to get the temperature from HA and to send HA the cooling setpoint. I'm then using Rule Machine on the HE side to populate a virtual thermostat that my HVAC automations can use. I mean if it's stupid and it works, it's not stupid. Right?
That is klunky... but if it works ???? OK
Or
Create a virtual thermostat in HE (not within my app*) and expose it to MQTT - you will see all the topics it provides. This will appear as a thermostat in HA... Link the two thermostats in HA with actions. Now you can control the HA thermostat from HE and continue to use your HE rules.
What you will be missing is updates from HA into HE. To do this you will use mappings taking the HA thermostat published state values (which appear under the HA statestream/climate/device... topic and putting them into some appropriate devices like a temperature sensor or a switch and then a rule to copy that to the HE virtual thermostat.
There's a catch22 here . If you create the virtual thermostat within HE you can publish it as a complete device from HE to MQTT and it will be discovered by HA. If you create it in my app you can't. You can control all the $settable topics by just issuing for example a
homie/hubname/thermostatname/heating-setpoint/set=23
command
If you create the device within my app you can update it's attributes from MQTT using the _MAP if needed. If you publish from HE you can't.
The above is an HE virtual thermostat device exposed to MQTT (and will be auto discovered by HA if that option is enabled). That discovery aspect is not well tested yet but looks to work
If you want me to help here possibly best to start a separate thread on this specific topic or to contact me by PM where I will be happy to try and assist.
I think you've got me headed down the right path. Thanks so much for your help!
I will at some time look at supporting thermostat discovery into HE - a few people have asked and my bug list is really short at the moment 
phew... so it's moving up the list.
If you need help just shout - I know the _MAP value feature is not well documented currently so it's quite understandable.
Actually if you could just list which 'values' (entities / attributes) you need bringing into HE from the HA thermostat and what control commands you would want to send back it maybe that I could do a partial implementation. Hopefully this is a short list (the screenshot above outlines all the attributes /commands a thermostat has )
It's a pretty short list. All I need from HA are state (cooling, idle) and measure-temperature. I have to send the cooling-setpoint to HA from HE.
So you are turning the AC off by raising the cooling setpoint ?
Download the Hubitat app
