So removed the thermostats from the client to server device list, deleted the thermostat devices on the server, and re-added them to the client to server list.
The 4 devices DO get created on the server side, though.
Also, I never get event updates in the replicated item for "thermostatOperatingMode", which happens to be attribute slot #8. Not sure the last attribute is sending events at all.
Now that I re-created the devices, I'm getting a little more logging.
Here is what I see in the logs for "thermostatFanState". Presumably the null in this is units (?). I base that guess on how a temperature reading event looks.
Still no Current State shown on replicated device, though.
And I still see nothing for thermostatOperatingState, and it has changed multiple times.
Let me know if there is anything else you want me to collect. I'm going to put this effort to the side until a few more releases come out and more users are using it - for what I need (custom drivers) it seems too buggy for now. Without being able to get custom drivers working, I can't move anything to my other hub anyway, so that is a pass/fail for using the app for me.
Awesome app, and awesome development, though! Really nice work! I'm sure a LOT of people are going to get use out of this.
No, they don't get deleted, they could be part of an Automation, etc.
yes, I'm waiting for hundreds more people to participate.
The Hubitat <--> Hubitat connectivity got a lot of testing, although rather specific, as you can tell from the stub driver names.
I've done a reasonable amount of testing of a Virtual Thermostat on one Hub being sent to the 'coordinator' and being displayed on Dashboard. I also have my Real (Honeywell Wifi) Thermostat and it's driver on a different Hub to 'coordinator' and displayed on Dashboard. (I just don't need to be bouncing temps up and down, fan on/off and Cool/heat every 6-12 seconds on a Real thermostat.)
I did not do any ST testing because my ST Hub has long been retired and I believed my accounts with Samsung would be long deleted. However, when I found that @srwhite has a v3 I decided it would be worth at least trying to bring my antique v2 back to life. It went far easier than I imagined because Samsung hadn't deleted anything!
It actually took longer for me to remember that you MUST use the App to add devices than restoring a functional hub to my home. I was clicking around in the IDE for the longest time...
FWIW, Hub Link/Link to Hub (I always forget which goes which way) does apparently remove devices it creates, or at least the useless/annoying virtual ones on the "host" hub (but I don't remember having to do it from the "client" hub, either, so I think it's both). I can see advantages to both ways, though I'm particularly happy with how Hub Link handles it since it creates a virtual device for every "server" device, something I'm thrilled to see HubConnect avoids.
This release fixes the issue where devices on SmartThings hubs were not being created on the server hub. It also addresses the http exception error that was occurring immediately following device creation.
It's me, your favorite problem child. With the latest update, I'm having problems with devices selected on the remote hub getting created on the server hub (both Hubitat). I don't see anything in the logs that suggests it's even trying. (I originally noticed problems with existing HubConnect switches claiming that they don't support "on" or "off" when I tried to change the switch state on the remote hub, so I figured I'd try recreating. Turns out, I can't.) The other direction works fine. Could I be doing something wrong, or is there something I could check? I've tried this on two different remote hubs and made sure the code was updated on all.
Updated to the latest release and I'm having this issue too. ST switches that worked yesterday are no longer working when a change is initiated on the HE side.
This is the error I'm getting on ST
8:38:47 AM: error The device [Hall Lights] does not support the command on.
8:38:47 AM: info Received command from server: ["Hall Lights": on]
If I turn it on via ST - the state change shows up properly in HE.
Did I miss something or do Virtual Devices not get shared? I have 2 virtual switches that I've selected on my client and they are not showing up on the server. There are no errors in the logs either.
I have several, but one I've documented before is a Virtual Thermostat on my 'upstairs hub' being sent to 'coordinator' and displayed on Dashboard. The image is up a few posts #308 called testThermo.
I'm technically having this problem too, but it's any device I choose on the client not showing up on the server after the latest update. Could that be happening to you, too, and this is just how you noticed it?
Not sure that's the fix (2 hrs ago) 15:37:40: error The device [Porch] does not support the command on.
Error in ST log ..controlled from coordinator back to ST
All current versions loaded. Devices deleted and recreated throughout.
