FYI - updated to 1.2 but still not able to get my ST valve to show up.
I noticed it had gone quiet too - and that seemed a good sign that everything was working.
From my experience it is , and very well. I don't have a lot of devices linked yet and so can't comment on the websocket advantages - but I am using websocket and it's working great. It is a shame it can't be efficiently filtered to be applied bidirectionally and I can appreciate there could be awful loop situations but I'm unlikely to be linking bucketloads of devices anyway.
I'm thinking through whether this app has a role to play in MQTT either by pushing HE devices onto a MQTT broker and updateable from same, or grabbing existing MQTT devices and getting them into HE. Using the HubConnect mechanisms of course. Thinking about where such a 'client' might run and about whether that's agreeable to the licence. Maybe eventsocket<>bridge<>mqtt sits better. Avoiding a bridge at all would be even better 
Thanks so much for this app Steve & @csteele - I'm really enjoying it.
Everyone is still working on importing each and every driver file. lol
2 Likes
I updated 4 hubs today - I'd previously taken a view to put all drivers on all hubs - something I regretted approaching 200 copy/pastes. There's got to be an easier way @Hubitat ?
2 Likes
Looks like the drivers all have an importUrl set in their definition now, so just clicking the "Import" button should populate the URL and allow you to grab and save the latest code without any manual copying and pasting on your part--just a lot of clicking if you have all the drivers on multiple hubs. 
For the app, once you paste the import URL into the "Import" button yourself once, it secretly saves that and will automatically populate the field in a similar fashion should you click "Import" again. Staff has commented here that they are looking for a way to unify this experience: Import Code from Website - Driver Code - #4 by chuck.schwer
The GitHub repo settings on ST still aren't working for me (doesn't see any files at all when I try HubitatCommunity / HubConnect / master), but I only have a few DTHs installed there, anyway.
2 Likes
Yeah, I put the raw URLs in so I can just import each time but that's still a lot of clicking around.
It's asking a lot of the Remote hub to filter out only what it needs, when one goal was to give the Remote Hub with it's larger set of physical devices, the processing power to run the radios. In a greater-than-two-hub architecture, there's an expectation of a 'coordinator' type hub that doesn't have radios and is 'idle' enough to be available to filter the Eventsocket.
I now have 3 hubs connected to 'coordinator' with one of them being a massively underloaded SmartThings hub. On the other hand, 'coordinator' is under utilized if my readings of my logging is a fair test. Seems like for my specific use case, I can get another 4 hubs talking to 'coordinator.'
Homebridge isn't phasing it, so maybe I should install WebCoRE just to keep the CPU warm? 
1 Like
Sorry, I been holding my 237 issues, I will post them in a few minutes.
By the way, I installed this to my friend's HE and ST hubs, working excellent.
1 Like
You posted 1 minute ago.. you should be to 239 issues by now. 
3 Likes
I've just seen this error in the logs, but no real way to see what triggered it.
dev:42252019-04-03 12:39:56.938 pm errororg.h2.jdbc.JdbcSQLException: General error: "java.lang.NullPointerException" [50000-197] on line 169 (parse)
--- Live Log Started, waiting for events ---
I was joking about the 237 issues but I got this error on the server logs, it's coming from ST instance
Thanks
Edit, I activated the debug on the ST instance and after saving I don't see this error anymore, lets wait until I get more logs to see if it returns. Thanks
What is device 4225? What driver is throwing that error, please?
I've gotten the same error, BUT, I've found a matching one on ST too:
63492fc2-63e3-49f9-9830-fa9a2cad6f11 9:53:03 PM: error java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in escape (%) pattern - For input string: ""," @line 454 (deviceEvent) app:488 2019-04-02 09:53:03.380 pm error httpGet() request failed with error 500
I think my thermostat was working well for a while, but now I've noticed errors when changing the setpoint via SmartThings (technically Alexa on SmartThings). I don't see any errors on ST (the remote thermostat I'm changing) or my "server" Hubitat hub, but I do see this on the "remote" Hubitat hub where the thermostat actually lives (so the thermostat is shared from remote Hubitat to server Hubitat to remote SmartThings and this error happens on the remote):
groovy.lang.MissingMethodException: No signature of method: zenZigbeeThermostat.fahrenheitToCelsius() is applicable for argument types: (java.lang.String) values: [51.0] (setHeatingSetpoint)
I don't think I noticfed this problem before upgrading to 2.0.8.112, so I'm not sure if it's a platform change or something with HubConnect, but I can't get this error to happen via any other method than attempting a change from ST (server or remote hubs in Hubitat both work as expected). Looks like it would be an easy string-to-integer (float?) conversion, but I'm not sure if this is something best addressed at the driver or app level.
Damn, that may take some digging. I've only seen that error once, more by chance than actually looking for it. Let me see if I can track it down.
I'll repeat, to see if I am understanding.. change setpoint from Alexa to ST to 'coordinator' to HE where the real device is Paired, The error is thrown by the Real Driver because the value is a String.
Is that correct?
What 'real' driver are you using? The Generic Zigbee Thermostat?
I didn't make it easy, but, yes, that correct (assuming "coordinator" and "HE where real device is paired" are two different hubs, which they are for me).
I am using the Zen Thermostat driver, the stock driver in Hubitat for this device since apparently they didn't roll it into the generic driver for some reason.
To eliminate the ST platoform, are you able to change the setpoint from the virtual device created on the server hub?
Out of all of the ST drivers I've made to day, this one received about a 4 hours of attention and testing. My scenario was very similar to yours...
ZWave T-Stat <--> Remote Hub <--> Server Hub <--> SmartThings
I was able to use all functions. I'm thinking there might be something specific with that Thermostat driver but I cannot be sure yet.
Let me know if you are able to control it from the virtual device on the server hub.
