Yes - am seeing this - currently a device created on ST from the coordinator appeared but is not updating. On state changes of this device nothing shows received in ST log or in the HE log showing events being forwarded. On adding a second device I got this error in the ST log.
groovy.lang.MissingMethodException: No signature of method: physicalgraph.app.AppStateCacheService.getAppState() is applicable for argument types: (java.lang.String, org.codehaus.groovy.grails.web.json.JSONObject) values: [f81963a2-7e7e-495c-98f6-e0cceca1a77e, [values:[switch], bytes:[...], ...]]
Possible solutions: getAppState(java.lang.String, java.lang.String), setAppState(java.lang.String, physicalgraph.app.cassandra.AppState) @line -1 (doCall)
Should I be able to set a HubConnect device up in the coordinator that is being updated from a local device on the remote HubA , but then additionally setup an additional HubConnect device on another remote HubB that is being updated from the coordinators HubConnect device ? A sort of forward effect..
I have 4 of those currently. All my Zigbee (9 devices) are on one hub. No point in two Zigbee meshes for 9 devices and 4 are the Iris motion v2 or v3. So I push those 4 to 'coordinator' where they are visible to Dashboard(s) and I also send them to the 2nd radio hub where they get used in Rules.
This is one of those cases where the strict division of devices by Floor isn't an ideal choice. I've mixed the motion sensor (vendors) per floor but they are all physically on a single hub/floor.
Mode flow outward from the coordinator out to SmartThings. These are simply text strings so it's vitally important that they match exactly across all hubs. I've been using mode changes across my hubs since I started coding HubConnect. If the mode changes aren't working in ST, check the logs for errors.
When I refactored a the to improve usability it appears that SmartThings was broken by that. The fixes for the ST platform will be out soon.
This is totally awesome. I haven't tried it yet but this may be the answer to me using a hub just for Homebridge and take that load off my other 2 hubs.
My only complaint... Man, that's a lot of drivers to load on 3 hubs.
This is probably the largest "Package" ever created for Hubitat, outside of the Hub itself.
You only need to install the drivers for the devices you are pushing.
I started with just the one required one and built from there. And they are so small, it takes very little time PLUS it speeds up via tabs for every hub and just Copy (from Github) and Paste, Paste, Paste. Next.
With HE stuff abstracted in this way the potential seems amazing.. Maybe this could also be used to connect a dashboard or any kind of hub-like device virtual or not.
Nice update! Device creation from Hubitat to ST is much improved for me. I did notice some odd DNIs, things like null:392, suggesting to me that however it's trying to get the first part of the ID (server IP?) isn't working. I don't doubt that I could have done something wrong here, so I'm open to suggestions.
Also, when I try to control a thermostat (Hubitat > ST, or technically Hubitat > Hubitat > ST), I get:
2019-03-26 10:01:48.788 [error] groovyx.net.http.HttpResponseException: Bad Request on line 610 (realtimeEventHandler)
2019-03-26 10:01:47.149 [debug] Sending event to server: Zen Thermostat [heatingSetpoint: 55.0 °F]
I think this is a general problem regarding sending event data any time after the initial creation (it promisingly populated with the correct data but hasn't changed since creation), and I think it's also a problem I'm having with all of my devices. The rest are just sensors and I can't manually cause something like this to happen, but I believe the same error happened with temperature on another sensor I have paired.
Again, could be something I'm doing wrong, but in any case, this is much better and more promising for me than before! (Oh, and in case I wasn't clear, all the errors I saw before during creation of the HubConnect devices on ST are gone.)
There could still be some ST-specific nuances that I need to capture. If you linked the thermostat before upgrading today, which I believe you likely did since @csteele and I caught that scenario during testing yesterday, it's best to delete it, then let HC recreate it. The DNI should be correctly populated at that point.
I deleted all of the HubConnect devices on ST before I upgraded the code. I just tried it again, and I'm still getting null: at the begnning of the DNI, along with the same errors on the Hubitat side (don't see anything in ST even though debug logging is on, so I'm not sure it's even getting that far) when I try to manipulate it.
I also tried completely removing and reinstalling the app on ST after again deleting the devices (just in case I still did something wrong before), and the behavior is the same.
I found that last night, but apparently my manually adding the IP to the DNI meant my next test (thinking it was found/fixed) didn't test enough. Sorry for that miss.
Just tried that now (it did seem to match up the existing device and not create a new one), but the same "line 610" error happens. I see that part of what it's trying to send in the encoded URL is this (decoded):
I'm assuming that null is part of the problem, either because it shouldn't be there or it's not wrapped in quotes despite the fact that it is there, but I definitely don't understand the code well enough to test this further yet.
and 4 are the Iris motion v2 or v3. So I push those 4 to 'coordinator' where they are visible to Dashboard(s) and I also send them to the 2nd radio hub where they get used in Rules.
I just tried it again, and I'm still getting 
