question, when password is ON, does you child switch works?
Some logs when I add the device password protected
dev:26622023-09-20 21:59:45.290debugHTTP Async Response: [id:112, auth:Digest] ::: [ble:[:], cloud:[connected:true], input:0:[id:0, state:false], input:1:[id:1, state:false], mqtt:[connected:false], switch:0:[id:0, source:switch, output:false, apower:0.0, voltage:234.0, freq:50.1, current:0.000, pf:0.00, aenergy:[total:3.110, by_minute:[0.000, 0.000, 0.000], minute_ts:1695239982], temperature:[tC:53.3, tF:127.9]], switch:1:[id:1, source:init, output:true, apower:8.7, voltage:234.1, freq:50.1, current:0.065, pf:0.57, aenergy:[total:11.624, by_minute:[110.919, 157.744, 155.167], minute_ts:1695239982], temperature:[tC:53.3, tF:127.9]], sys:[mac:B8D61A88F910, restart_required:false, time:21:59, unixtime:1695239984, uptime:1077, ram_size:243132, ram_free:128320, fs_size:458752, fs_free:143360, cfg_rev:46, kvs_rev:0, schedule_rev:0, webhook_rev:0, available_updates:[:]], wifi:[sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-65], ws:[connected:false]]
dev:26622023-09-20 21:59:45.246debugHTTP Async Response: [id:112, auth:Digest] ::: [ble:[:], cloud:[connected:true], input:0:[id:0, state:false], input:1:[id:1, state:false], mqtt:[connected:false], switch:0:[id:0, source:switch, output:false, apower:0.0, voltage:234.0, freq:50.1, current:0.000, pf:0.00, aenergy:[total:3.110, by_minute:[0.000, 0.000, 0.000], minute_ts:1695239982], temperature:[tC:53.3, tF:127.9]], switch:1:[id:1, source:init, output:true, apower:8.7, voltage:234.1, freq:50.1, current:0.065, pf:0.57, aenergy:[total:11.624, by_minute:[110.919, 157.744, 155.167], minute_ts:1695239982], temperature:[tC:53.3, tF:127.9]], sys:[mac:B8D61A88F910, restart_required:false, time:21:59, unixtime:1695239984, uptime:1077, ram_size:243080, ram_free:126912, fs_size:458752, fs_free:143360, cfg_rev:46, kvs_rev:0, schedule_rev:0, webhook_rev:0, available_updates:[:]], wifi:[sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-65], ws:[connected:false]]
dev:26622023-09-20 21:59:45.198infoHTTP authtentification sequence...
dev:26622023-09-20 21:59:45.163infoHTTP authtentification sequence...
dev:26622023-09-20 21:59:45.138debugHTTP Async query: Shelly.GetStatus([:])
dev:26622023-09-20 21:59:45.104debugHTTP Async query: Shelly.GetStatus([:])
dev:26622023-09-20 21:59:45.100errorconfigure: status code: 401, reason phrase: Unauthorized. Can't configure child devices. Please, re-try.
dev:26622023-09-20 21:59:45.048debugHTTP authtentification sequence...
dev:26622023-09-20 21:59:45.046debughttpGet incident: groovyx.net.http.HttpResponseException: status code: 401, reason phrase: Unauthorized
dev:26622023-09-20 21:59:45.009debugHTTP Sync query: Shelly.GetStatus([:])
dev:26622023-09-20 21:59:45.006infoVersion Report Generic - FirmwareVersion: 1.0.3, ProtocolVersion: 2, HardwareVersion: SNSW-102P16EU
dev:26622023-09-20 21:59:45.004infoDevice info response [name:null, id:shellyplus2pm-b8d61a88f910, mac:B8D61A88F910, slot:1, model:SNSW-102P16EU, gen:2, fw_id:20230912-081945/1.0.3-g6176478, ver:1.0.3, app:Plus2PM, auth_en:true, auth_domain:shellyplus2pm-b8d61a88f910, profile:switch]
dev:26622023-09-20 21:59:45.001debugHTTP Sync Response: [name:null, id:shellyplus2pm-b8d61a88f910, mac:B8D61A88F910, slot:1, model:SNSW-102P16EU, gen:2, fw_id:20230912-081945/1.0.3-g6176478, ver:1.0.3, app:Plus2PM, auth_en:true, auth_domain:shellyplus2pm-b8d61a88f910, profile:switch]
dev:26622023-09-20 21:59:44.960debugHTTP Sync query: Shelly.GetDeviceInfo([:])
dev:26622023-09-20 21:59:44.958infoInitial value
dev:26622023-09-20 21:59:44.955infoReconnecting in 30 seconds.
dev:26622023-09-20 21:59:44.953infoInitial value
dev:26622023-09-20 21:59:44.950infoConnection failed: Connection reset
dev:26622023-09-20 21:59:44.948infoInitial value
dev:26622023-09-20 21:59:44.945infoInitial value
dev:26622023-09-20 21:59:44.941infoInitial value
dev:26622023-09-20 21:59:44.938infoInitial value
It seems there is some issue with websocket connection in password protected mode (HTTP queries are working just fine) From what I see device resets connection each time when receiving command. I'll nvestigate tomorrow in depth.
Update:
A driver with authentification fix is submitted.
The problem in fact were only related to HTTP requests that had 'query' property set. Authentification encoding were ignorring url query part.
Also this property does not handle empty container correctly on the Hubitat side (it should be either non-empty or null; it generates weird behavior if set to [:]).
Side note: if password was changed without rebooting shelly device, the driver will need to be reconnected (disconnect/connect). The driver has no feedback on if password were changed or not. Otherwise old stream will remain open. Device allows opening unauthentificated stream. But in this case device will not respond to websocket commands while continuing to send events back to the hub.
This one can be improoved. Device sends event about configuration change (without specific details). It can be used for autoreconnection (and failure till proper password is set)
A side of it a guard check is added in case if shelly add-on module is attached. As add-on components have ids starting 100 the driver could spawn quite a bunch of ghost child devices. For the moment add-on units are not supported (will be simply ignored).
1 Like
Yep, issue solved:-)
Sometimes I see an error, any idea?
Password is OK, everything is working fine
Logs
dev:26622023-09-22 19:59:44.206debugparseShellyWifiStatus [sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-58]
dev:26622023-09-22 19:59:44.203infoConfiguration revision 48
dev:26622023-09-22 19:59:44.179info(192.168.178.140 temperature sensor 2) Sensor generic report: Air temperature:temperature 43.5°C
dev:26622023-09-22 19:59:44.176debug(192.168.178.140 temperature sensor 2) parseShellyTemperatureSensorStatus [tC:43.5, tF:110.3]
dev:26622023-09-22 19:59:44.148info(192.168.178.140 switch 2) Meter generic report: Electric:voltage 236.6V
dev:26622023-09-22 19:59:44.145info(192.168.178.140 switch 2) Power factor 0.00
dev:26622023-09-22 19:59:44.117info(192.168.178.140 switch 2) Sensor generic report: Frequency:frequency 50.0Hz
dev:26622023-09-22 19:59:44.084info(192.168.178.140 switch 2) Meter generic report: Electric:amperage 0.0A
dev:26622023-09-22 19:59:44.055info(192.168.178.140 switch 2) Meter generic report: Electric:power 0.0W
dev:26622023-09-22 19:59:44.027info(192.168.178.140 switch 2) Meter generic report: Electric:energy 0.003451kWh
dev:26622023-09-22 19:59:44.024debug(192.168.178.140 switch 2) parseShellyCommonStatus [id:1, source:HTTP_in, output:false, apower:0.0, voltage:236.6, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]]
dev:26622023-09-22 19:59:44.001debug(192.168.178.140 switch 2) parseShellySwitchStatus [id:1, source:HTTP_in, output:false, apower:0.0, voltage:236.6, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]]
dev:26622023-09-22 19:59:43.970info(192.168.178.140 temperature sensor 1) Sensor generic report: Air temperature:temperature 43.5°C
dev:26622023-09-22 19:59:43.960debug(192.168.178.140 temperature sensor 1) parseShellyTemperatureSensorStatus [tC:43.5, tF:110.3]
dev:26622023-09-22 19:59:43.916info(192.168.178.140 switch 1) Meter generic report: Electric:voltage 236.5V
dev:26622023-09-22 19:59:43.913info(192.168.178.140 switch 1) Power factor 0.00
dev:26622023-09-22 19:59:43.872info(192.168.178.140 switch 1) Sensor generic report: Frequency:frequency 50.0Hz
dev:26622023-09-22 19:59:43.843info(192.168.178.140 switch 1) Meter generic report: Electric:amperage 0.0A
dev:26622023-09-22 19:59:43.810info(192.168.178.140 switch 1) Meter generic report: Electric:power 0.0W
dev:26622023-09-22 19:59:43.779info(192.168.178.140 switch 1) Meter generic report: Electric:energy 0.005091kWh
dev:26622023-09-22 19:59:43.775debug(192.168.178.140 switch 1) parseShellyCommonStatus [id:0, source:button, output:false, apower:0.0, voltage:236.5, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]]
dev:26622023-09-22 19:59:43.747debug(192.168.178.140 switch 1) parseShellySwitchStatus [id:0, source:button, output:false, apower:0.0, voltage:236.5, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]]
dev:26622023-09-22 19:59:43.740debug(192.168.178.140 input 2) parseShellyCommonStatus [id:1, state:false]
dev:26622023-09-22 19:59:43.737info(192.168.178.140 input 2) Input state false
dev:26622023-09-22 19:59:43.714debug(192.168.178.140 input 2) parseShellyInputStatus [id:1, state:false]
dev:26622023-09-22 19:59:43.711debug(192.168.178.140 input 1) parseShellyCommonStatus [id:0, state:null]
dev:26622023-09-22 19:59:43.691debug(192.168.178.140 input 1) parseShellyInputStatus [id:0, state:null]
dev:26622023-09-22 19:59:43.688debugparseShellyCloudStatus [connected:true]
dev:26622023-09-22 19:59:43.682debugHTTP Async Response: [id:112, request:[uri:http://192.168.178.140, path:/rpc/Shelly.GetStatus, requestContentType:application/json, headers:[Authorization:Digest username="admin", realm="shellyplus2pm-b8d61a88f910", qop=auth, algorithm=SHA-256, uri="/rpc/Shelly.GetStatus", nonce="1695405580", nc=1, cnonce="1695405580", opaque="", response="6fa1483f8c85992e43089edc9ff4b0654552d9a6db37f237f2bdbfa31c0d6a0b"]], auth:Digest] ::: [ble:[:], cloud:[connected:true], input:0:[id:0, state:null], input:1:[id:1, state:false], mqtt:[connected:false], switch:0:[id:0, source:button, output:false, apower:0.0, voltage:236.5, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]], switch:1:[id:1, source:HTTP_in, output:false, apower:0.0, voltage:236.6, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405579], temperature:[tC:43.5, tF:110.3]], sys:[mac:B8D61A88F910, restart_required:false, time:19:59, unixtime:1695405581, uptime:79170, ram_size:243228, ram_free:132020, fs_size:458752, fs_free:143360, cfg_rev:48, kvs_rev:0, schedule_rev:0, webhook_rev:0, available_updates:[:]], wifi:[sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-58], ws:[connected:false]]
dev:26622023-09-22 19:59:43.577infoHTTP authtentification sequence...
dev:26622023-09-22 19:59:43.478errorUnauthorized WS query. Please, check your password.
dev:26622023-09-22 19:59:43.458debugHTTP Async query: Shelly.GetStatus([:])
dev:26622023-09-22 19:59:43.436debugWS query: {"params":{id:0}, "id":80, "method":"Input.GetStatus", "src":"hub", "auth":{"username": "admin", "realm": "shellyplus2pm-b8d61a88f910", "algorithm": "SHA-256", "nonce": "1695401960", "cnonce": "1695401960", "response": "44bf1c8627e8f4ee7bd354037f7925706472ea5da10e5e71c07f5056698fdcac"}}
dev:26622023-09-22 19:59:43.432infoReceived 'refresh' request from 192.168.178.140 input 1 (EP1)
dev:26622023-09-22 19:59:43.360infoReconnecting in 30 seconds.
dev:26622023-09-22 19:59:43.355infoConnection failed: Connection reset
dev:26622023-09-22 19:59:13.902debugparseShellyWifiStatus [sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-58]
dev:26622023-09-22 19:59:13.899infoConfiguration revision 48
dev:26622023-09-22 19:59:13.874info(192.168.178.140 temperature sensor 2) Sensor generic report: Air temperature:temperature 43.6°C
dev:26622023-09-22 19:59:13.871debug(192.168.178.140 temperature sensor 2) parseShellyTemperatureSensorStatus [tC:43.6, tF:110.4]
dev:26622023-09-22 19:59:13.842info(192.168.178.140 switch 2) Meter generic report: Electric:voltage 235.9V
dev:26622023-09-22 19:59:13.839info(192.168.178.140 switch 2) Power factor 0.00
dev:26622023-09-22 19:59:13.811info(192.168.178.140 switch 2) Sensor generic report: Frequency:frequency 50.0Hz
dev:26622023-09-22 19:59:13.783info(192.168.178.140 switch 2) Meter generic report: Electric:amperage 0.0A
dev:26622023-09-22 19:59:13.754info(192.168.178.140 switch 2) Meter generic report: Electric:power 0.0W
dev:26622023-09-22 19:59:13.728info(192.168.178.140 switch 2) Meter generic report: Electric:energy 0.003451kWh
dev:26622023-09-22 19:59:13.725debug(192.168.178.140 switch 2) parseShellyCommonStatus [id:1, source:HTTP_in, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]]
dev:26622023-09-22 19:59:13.698debug(192.168.178.140 switch 2) parseShellySwitchStatus [id:1, source:HTTP_in, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]]
dev:26622023-09-22 19:59:13.669info(192.168.178.140 temperature sensor 1) Sensor generic report: Air temperature:temperature 43.6°C
dev:26622023-09-22 19:59:13.666debug(192.168.178.140 temperature sensor 1) parseShellyTemperatureSensorStatus [tC:43.6, tF:110.4]
dev:26622023-09-22 19:59:13.637info(192.168.178.140 switch 1) Meter generic report: Electric:voltage 235.9V
dev:26622023-09-22 19:59:13.634info(192.168.178.140 switch 1) Power factor 0.00
dev:26622023-09-22 19:59:13.604info(192.168.178.140 switch 1) Sensor generic report: Frequency:frequency 50.0Hz
dev:26622023-09-22 19:59:13.574info(192.168.178.140 switch 1) Meter generic report: Electric:amperage 0.0A
dev:26622023-09-22 19:59:13.544info(192.168.178.140 switch 1) Meter generic report: Electric:power 0.0W
dev:26622023-09-22 19:59:13.515info(192.168.178.140 switch 1) Meter generic report: Electric:energy 0.005091kWh
dev:26622023-09-22 19:59:13.512debug(192.168.178.140 switch 1) parseShellyCommonStatus [id:0, source:button, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]]
dev:26622023-09-22 19:59:13.483debug(192.168.178.140 switch 1) parseShellySwitchStatus [id:0, source:button, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]]
dev:26622023-09-22 19:59:13.479debug(192.168.178.140 input 2) parseShellyCommonStatus [id:1, state:false]
dev:26622023-09-22 19:59:13.476info(192.168.178.140 input 2) Input state false
dev:26622023-09-22 19:59:13.452debug(192.168.178.140 input 2) parseShellyInputStatus [id:1, state:false]
dev:26622023-09-22 19:59:13.449debug(192.168.178.140 input 1) parseShellyCommonStatus [id:0, state:null]
dev:26622023-09-22 19:59:13.427debug(192.168.178.140 input 1) parseShellyInputStatus [id:0, state:null]
dev:26622023-09-22 19:59:13.424debugparseShellyCloudStatus [connected:true]
dev:26622023-09-22 19:59:13.421debugHTTP Async Response: [id:112, request:[uri:http://192.168.178.140, path:/rpc/Shelly.GetStatus, requestContentType:application/json, headers:[Authorization:Digest username="admin", realm="shellyplus2pm-b8d61a88f910", qop=auth, algorithm=SHA-256, uri="/rpc/Shelly.GetStatus", nonce="1695405550", nc=1, cnonce="1695405550", opaque="", response="01ae6017f8d0b6b8d2408591ad2bfe539b95c9fa250459f4bb260c86545340bb"]], auth:Digest] ::: [ble:[:], cloud:[connected:true], input:0:[id:0, state:null], input:1:[id:1, state:false], mqtt:[connected:false], switch:0:[id:0, source:button, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:5.091, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]], switch:1:[id:1, source:HTTP_in, output:false, apower:0.0, voltage:235.9, freq:50.0, current:0.000, pf:0.00, aenergy:[total:3.451, by_minute:[0.000, 0.000, 0.000], minute_ts:1695405549], temperature:[tC:43.6, tF:110.4]], sys:[mac:B8D61A88F910, restart_required:false, time:19:59, unixtime:1695405550, uptime:79140, ram_size:243124, ram_free:130856, fs_size:458752, fs_free:143360, cfg_rev:48, kvs_rev:0, schedule_rev:0, webhook_rev:0, available_updates:[:]], wifi:[sta_ip:192.168.178.140, status:got ip, ssid:Antartica, rssi:-58], ws:[connected:false]]
dev:26622023-09-22 19:59:13.341debug(192.168.178.140 input 1) parseShellyCommonStatus [id:0, state:null]
dev:26622023-09-22 19:59:13.332infoHTTP authtentification sequence...
dev:26622023-09-22 19:59:13.316debug(192.168.178.140 input 1) parseShellyInputStatus [id:0, state:null]
dev:26622023-09-22 19:59:13.248debugHTTP Async query: Shelly.GetStatus([:])
dev:26622023-09-22 19:59:13.244debugWS query: {"params":{id:0}, "id":80, "method":"Input.GetStatus", "src":"hub", "auth":{"username": "admin", "realm": "shellyplus2pm-b8d61a88f910", "algorithm": "SHA-256", "nonce": "1695401960", "cnonce": "1695401960", "response": "44bf1c8627e8f4ee7bd354037f7925706472ea5da10e5e71c07f5056698fdcac"}}
dev:26622023-09-22 19:59:13.233infoReceived 'refresh' request from 192.168.178.140 input 1 (EP1)
dev:26622023-09-22 19:59:13.192infoReconnecting in 30 seconds.
dev:26622023-09-22 19:59:13.186infoConnection failed: Connection reset
This specific error usually happens when dvice password were changed without rebooting device. Stream remains connected (with old password). So reconnection should remove it. Reconnection will eventually happen implicitely when device or hub reboots.
If you constantly see deriver reconnection sequence each 30S ( dev:26622023-09-22 19:59:43.360infoReconnecting in 30 seconds.), this means something goes wrong. Normally connection should remain open.
From what I can see there are some changes either in the shelly device behavior or in the hub logic. When I manually disconnect, WS returns failure while originally it should return 'closing' state. But when device reboots it closes stream gracefully (and so connection is not auto restored). I cannot affetc returned status. But I'll improove reconnection behavior.
1 Like
OK, I did a reboot/connect of the device, will see
I updated driver:
Somewhat improved connection/disconnection logic. Still there is a weird error reported when disconnected by hub/driver initiative. Don't know if it is a hub making dirty disconnect or a device connot handle it correctly. Anyway it has no negative impact in the end except warning entry in log.
Fixed cover child device thresholds. And added energy threshold to cover and switch devices
Somewhat improved logging. Now it can be set to "Errors and warning only", "Info" or "Debug" instead of on/off giving more control over verbosity.
1 Like
correct, when everything is ok I see this in the log for the switch
If not ok I see this:
After a disconnect /connect it is solved.
The problem starts on the red line. On that moment I changed the logging on the parent from Error/warnings only to info
Parent log
Could you describe what do you mean by "ok" and "not ok"? Do you mean reconnection loop?
Also I did one more change to logging: While driver is now using 'logLevel' instead old input control, old 'logEnable' remains in sort of ghost mode. It is not declared anymore but still has the last value. I had to completely remove any references to it in all drivers to not to use 'compatibility' code. Now Error/warning should not spam with "info".
Regarding warning message.. It pops up at saving settings as it calls disconnect and connect to update stream in case of password change (to apply new credentials).
And disconnect call cases that warning (that "connection reset") to pop (while it shouldn't but still..).
1 Like
ok= when en there is NO reconnecting in 30seconds
NOK= reconnect each 30 seconds
For some reason you need to disconnect /reconnect after a change of the Logging level on the parent, otherwise I see the connection failure
A bit of a headache with this one. But with fresh update should be working correctly now.
Here is a thing:
websocket API has no state exposed and stream state callback does not provide any data about what cause it (like function call, stream data corruption, etc; nor any 'user data' that could help when provided trough function call)
To change callback behavior depending on operation context it needs some driver state provided to it. But callback implicitely has multithreading execution policy. I.e. if calling function will set some regular driver state callback might not see it as state has sort of caching mechanism. So it is might not get properly updated. And calling 'disconnect' and 'connect' in a row triggers this case.
The driver is now using atomicState for the purpose.
2 Likes
Just added experimental support for DevicePower component. Shelly H&T now should report battery/mains (blindly added; no device to test at hand)
1 Like
Hi Dmitry, some questions about you nice driver 
.
When I accidental hit the configure button or after changing the device profile and hit configure is needed all child devices are replaced by new ones
Should the existing childs not be overwritten/updated instead of replaced by new ones?
What is the correct procedure when there is an update of the driver, do I need to hit initialize after install of the bundel? When should I use initialize?
Has the buttons "check for updates" & "Update version Info" no overlap?
Should the password not be hidden?
For other (zigbee) devices some developers use health status, very useful if the connection between the hub and device become unavailable for reporting Apps. The Health status is online or offline. Is it an option to change Link to Health status? [Project] Device Health Status so we can use it easy in the reporting tools to?
Any plans to put the driver in HPM, easy to keep the driver up to date?
Or use a bundle for Shelly devices only?
Path_Device path, what is the meaning of this field, in what scenario should I change it?
I wonder why you don't use the System Generic Components, Button Controller, Switch, Energy Meter, Energy Meter, etc... Does it not make your life as developer more easy?
The system Generic Component Temperature Sensor is used in you driver.
Yes. During configuration all devices are recreated. This allows to cleanup "foreign" child deices if any. I was thinking on some merged version that should inteligently add/remove devices to minimize inconvinience.
"Initialize" is called by the HUB itself on system boot. It opens event stream. Same as "Connect". I cannot hide it. This way hubitat API is made. No need to use this button by hand.
"CheckForUpdates" literally asks device to do so on Shelly servers.
"UpdateVersionInfo" asks device about currently installed FW/HW/SW and updates info in the data section. With recent changes this is mostly done automatically (as driver monitors FW update process). Hovewer device can be updated in offline mode without hub knowing this. And later with this button info can be updated manually.
I need to check if input widget has attribute to mask out password.
Yep. It's easily doable. I just need to rename the "link" attribute. If this naming convention is strong accross differnt app it will be perfect.
Didn't thought about it yet.
I can add one. Though maintaining multiple bundles will add complexity for lazy me))))
From backward compatibility perspective it is quite logical to use versioned endpoint in case of protocol version progression. So at the beginning I decided to expose endpoint path in case if let's say there will be some "/rpc2" endpoint. But it is not used (for any customization) in fact.
Yes, it does. The main reason is the lack of some attributes.
Input device aside of "contact" provides "event"
Metered cover and switch add power line status (voltage, amperage, power, energy and frequency [since recent FW update])
Illuminance component device is simply missing.
Same for battery device
P.S.: Metered devices also have thresholds to mitigate event spam. Device may report changes way to frequently/aggresively. Threshold allow to skip attribute changes if they are not big enough.
1 Like
would be very nice:-)
That would be very useful if you could do this;-)
@kkossev can you tell everything about:-)
After updating the driver using the bundel, do I need to do something?
No.
Bundle is a bunch of files. Updating bundle is the same as if you update all the files one by one.
Doing something after bundle update may be needed in some cases. if for example child device types changed. Then obviously you need to update child device instance set (and therefore reconfigure).
For attribute renaming there is nothing to reconfigure. Old attribute will just vanish with all the event history. And new one will appear.
2 Likes
Hi @dmitry.rozovik , the device is powered on/link is online, when there is a power cut for 1 min the link becomes OFFLINE, when the power comes UP , the device LINK stays OFFLINE waiting 5min+
I should think it reconnects after 30 seconds, it don't:
Is this as expected?
I it possible to add/show a driver version, easy to see If we are using the latest version....
If it were not explicitely disconnected (by issuing 'disconnect' command) it should not.
Ahhh... atomicState is not working. It is kinda there (no compilation errors) but it silently does nothing ((
Need to think how to handle it the other way around..
Update:
The driver is updated. Had to rollback to the original non-atomic state. Now connection is sligtly delayed to make 'update' function fully exit and flush 'state' changes.
P.S.: The thing is probably not in atomicState is not working but rather that websocket API control routines are asynchronous. And interface semantic policy differs from async http adding frustration. I.e. it is not clear that websocket.connect and websocket.close are asynchonous. And documentation has no mentions about that. So I have to guess if connection/disconection is complete after leaving websocket function or it is just started/scheduled.
1 Like
It is actually sounds like a feature request to Hubitat team. Versioning has quite wide adoption across different custom drivers. It makes sense to promote it to the driver definition section right next to the 'name', 'namespace' and 'author' properties. Also maybe some sort of getter function and a widget semewhere in the driver UI data section.
2 Likes
