Integrate deCONZ

"websocketport": 8081,

image

settings?.WebSocketPort

interfaces.webSocket.connect("ws://${settings.ip}:${settings.WebSocketPort}/")

sorry look like a error on my code im fixing it now. just confirm get


conect to url ws://192.168.1.50:8081 see if you get something there ones you press any button pair to deCONZ

I am seeing my devices reported in your app logs now..
I have an error reported with ws://192.168.1.50:8081 - checking why

line 189 of the parent drive interfaces.webSocket.connect("ws://${settings.ip}:${settings.WebSocketPort}/")//Connect the webSocket
this is the error
and look like you already spot it

1 Like

Thanks Jorge for all your help...

Just a quick tangent question - are you looking at another app for zigbee2mqtt or zwave2 mqtt support at all ?

One thing I have noticed is that the websocket connection resets the ip field from 192.168.1.50 (routable) to 172.30.33.3 (non routable) the Docker internal address. Because I assume that's what the .../config is showing ... I don't think I can override that and I think it causes..

'[debug] failure: connect timed out`

[debug][attr:[lastannounced:2020-09-26T14:57:24Z, lastseen:2020-09-26T17:12Z, manufacturername:IKEA of Sweden, modelid:FYRTUR block-out roller blind .etc
[debug]server connection= 172.30.33.3:40850
[debug]Sending on GET request to [https://dresden-light.appspot.com/discover] 
[debug]Discovering hub

I am not sure as you're going via the Dresden discover if the 172.30.33.3 address is not what you will need - it maybe..

ok looking in to that now

did you anything on the websocket client?

1 Like

Still looking as to why that didn't work.. strange
I am not sure PostMan supports ws://
I cant use your suggestion as Chrome addins are disabled as they crash Chrome currently on startup

as a test comment lines 124 and 125
// device.updateSetting("ip",internalipaddress)
// device.updateSetting("port",internalport)
there is the only place in the driver that update the ip and port
but I got the feeling that the hub cant get to the WS port

I been looking into this for a while I want to get all zigbee devices off the hubitat hub in to something dedicate it

1 Like

It is now not updating the ip field...
The connect which I assume is derived from the Dresden config response still goes to the Docker address though

server connection= 172.30.33.3:40850
Sending on GET request to [https://dresden-light.appspot.com/discover]

as a test change line 191 to
interfaces.webSocket.connect("ws://192.168.1.5:8081/")//Connect the webSocket
then click connect on the driver page

Sorry phone call - I had that originally (before the settings value) and it behaves the same (actually not the hardcoded IP)
server connection= 172.30.33.3:40850
But I am fairly sure the ip field is now fixed on 192.168.1.50

Let me look where that connect message is generated from
I do get device messages in the log
[attr:[lastannounced:2020-09-26T14:57:24Z, lastseen:2020-09-26T17:50Z, manufacturername:IKEA of Sweden, modelid:FYRTUR block-out roller blind, ...

Note this is on the 40850 port not the WS port

it will keep showing that but is not updating the settings so went you hit connect will connect to the ip in the ip field or if or if you change the line 191 will connect to wherever you put there

IP is hardcoded events come through as expected..

[e:changed, id:1, r:lights, state:[bri:208, lift:82, on:true, open:true, reachable:true], t:event, uniqueid:00:0d:6f:ff:fe:2e:e2:32-01]

Not sure if it's working or not - no child device created - you think the ws is not connected or the api not accessible (or both are working) ? I'll look through the code, I can probably debug this myself - or maybe it's working now..

press any key on one off the devices if is connected will generate a child device

it seem connected now actually but i don't have an implementation for lights yet Im getting a couple from ikea this afternoon and a possibly a roller

Ahh OK good - You're using your own virtual device drivers - rather than creating 'virtual switches' and 'virtual dimmers' etc leveraging the inbuilt HE drivers? Which is what I've done with my MQTT app.

I think I'm all set to play now and very interested in any zwave2mqtt implementation you're working on. My goal was to have my C7 as the main controller populating deConz and zwave2mqtt (maybe zigbee2mqtt) as HE's implementation is good. I have other controllers that will use deConz or zwave2mqtt too. Unfortunately my experience with C7 Z-Wave is making me rethink.

sound very good im changing my approach to that later this afternoon thanks

1 Like