I get the following on occasion. It seems that the only way to clear it is to go into the app and hit done. And when it says warning, it doesn't work. The only way I notice it is when something doesn't work. I looked in events and the log and nothing is shown.
Would it be wrong of me to guess it's a ST Cloud issue?
More reason to think of the Cloud first.
In the situation you've shown, ST is the Remote.. it's the Hub with all the devices... HubConnect is just a Listener. ST has an event, it sends the event through ST cloud to the HubConnect Remote Client and then into your HubConnect Server, which has a persistent connection to ST cloud. No logs on server means the event didn't leave the ST Cloud.
When I have an event, originated on ST, my HubConnect Server sees logs like:
app:65 2019-07-08 12:41:34.170 pm info Received event from ZeeSmart/TestSTthermo: [heatingSetpoint, 22 °C]
app:65 2019-07-08 12:41:33.901 pm info Received event from ZeeSmart/TestSTthermo: [thermostatSetpoint, 22 °C]
In my case it's the other direction. I'm not using ST to send things to HE, but HE to ST. And when it says WARNING it is not sending anything to ST. I know that ST is online and working as I can test that. But HE isn't communicating to it.
"Warning" is strictly the status of Ping. It's failed a couple of times. Remember, that page isn't dynamic. You'd have to use your Browser's refresh to see the up-to-the-minute info... or the logs.
The direction of the flow of 'desired data' is completely independent of Ping. Ping is there to do exactly what you're seeing.. those times when the connection from your hub, out the internet, and into ST's cloud is degraded or stopped. Your ST Hub is not really in the equation, since the Remote Client is actually running in ST's Cloud.
OK, I'll buy that. But what got me looking was nothing was going to ST for a period of time. I went into the HubConnect app, hit done and it immediately started working again. That is what concerns me that it doesn't fix itself.
I wouldn't use it at all if HE would get contact data to Alexa set up. That's about the only thing I use ST for now is to send contact data to Alexa to use in a routine. Or a better solution would be for Alexa to let switches trigger a routine, but doubt that is going to happen.
I think that is the persistent connection being dropped/rebuilt. I remember @srwhite saying something about making that more robust in v1.5... but he's off in his Camper, I believe. I haven't heard from him in several weeks.... didn't even get a "not missing you" postcard. Or is not getting one how you know that you're not missed?
Ok, so here's a fun one that I just now came across.
I have a pair of Sengled PAR38 outdoor bulbs that have a built in motion sensor. I've just recently, within the hour actually, been able to get the motion part to work to trigger things other than the lights themselves. The motion part doesn't show up as a child device, just an additional 'state' for the device. I have the lights shared but as a "switch" so motion reporting doesn't come across with connect. Could there be a driver written for HubConnect that will allow this one device to be both a light and a motion sensor?
For now I've worked around this by creating a light group on the client with my 2 floods called "Front Floods". I share that using HubConnect as a "switch" so I get on/off. Then I share the individual foods as motion sensors so I can use them as motion on the coordinator.
If I look at Hubitat's Virtual Thermostat driver, I can see it's Capabilities, Attributes, and Commands and Then I can look at the HubConnect 'reflection' of that device and see it's Capabilities, Attributes, and Commands.
I'll fix it next week when I'm home (unless work let's up and I can get to it this week while in Wales).
I had to do the same thing for my enhanced gocontrol thermostat driver, so I'm pretty sure I know what needs to be done.
@vjv Give this a try. I literally only had 5 minutes between meetings, so didn't put a lot of thought in it. I essentially copied over the needed parts from my GoControl driver. Looked like it should work on first blush. Entirely possible that you may have to cycle the mode off and back to cool/heat/auto and also make a setpoint change to initialize the variables - I didn't check the initialization part closely I will later though). https://raw.githubusercontent.com/Botched1/Hubitat/master/Drivers/Remotec%20ZTS-500US/Remotec%20ZTS-500US.groovy
If working correctly you should get a lastRunningMode and thermostatSetpoint value populated.
Also, by the way- did the 1.4.1 version fix the battery reporting?
@csteele I have a Denon AVR and created a new "HubConnect AV Receiver" driver based on the switch and dimmer since they are somewhat similar to the commands of the AVR drivers. I couldn't use the Custom Driver feature because it lacks the AudioVolume capability which provides mute, unmute, setVolume, etc commands that @cstory777 and others would be looking for .
I connected my Dev hub to my coordinator hub, added my Denon receiver as a switch and the device was created automagically on my dev hub. I then changed the driver to this custom driver and all the commands work as they should including setting the input, volume, mute, etc on the server hub. Only issue is additional plumbing is necessary in the HubConnect Apps by you or @srwhite to push the updates from the server hub with the AVR to the remote hub because the volume, mute, etc attributes aren't available on the remote hub. I am happy to explore these updates if you like, wasn't sure how open you two are with pull requests. I also have an Onkyo receiver and the driver is very similar to Denon so I believe a universal "HubConnect AV Receiver" driver would work.
As I've mentioned, I created the driver (too) and done the changes within Remote-Client for selecting, although I like your workaround.
I collaborate with @srwhite, I do not 'own' HubConnect. As I said elsewhere: My role is "burr under the saddle" so as to 'push' him exactly where he wanted to go anyway. I cannot 'Release' a new version of his code, in my personal opinion.
The reason I mention this is because he may disagree with my exuberance at building in this capability. As he's mentioned, this time of year is when he takes his camper to 'the wilds' (which has it's own Hub, connected to his 3 hubs at home.) When the weather turns and he returns, he may choose a different path. I'm not saying he would, just 'might.'
I can 'release' my version of the Universal Driver (because it's standalone,) BUT be aware of the possibility that it gets deleted/altered in the future.
OK?
oh and @ritchierich, PM me your driver so that at least one debugging cycle is saved
Or is not getting one how you know that you're not missed? 
