openLuup: Shelly Bridge plugin
-
Tried out the latest software:
-
line 583: The newinfo.ip is null, so the software does a return and no device is created. I think, if a static address is set up in the Shelley, this may return an IP address. But I'm using DCHP with statics set there.
-
I bypassed the return code by setting the ip address to "1.1.1.1". At line 588 sys.device.name is null. So I gave it a fake name "Shelley_Name" regardless later on you seem to have populated with shellyplusht-<the_id>.
-
After setting up the bypass: the parent device was created with the two children. The handler is hit every five minutes and only stops running once it realises the device already exists in function init_device() at line 463. Can this exit be determined earlier in the handler (just my OCD on wasted CPU cycles)?
-
The children aren't populated. You have to subscribe to "shellyplusht-<the_id>/events/rpc". Refer to this guys vid. And then look specifically for the event that contains this "method": "NotifyFullStatus". It contains all the good info.
-
You can then get the temp & humidity and also the ip address. The battery info has a flag indicating if running of USB (ie 5 Volts) or not. The device id is the Mac address. When you read the mac address, it has had all the colons or dashes removed. Can they be put back in when the MAC address is stored in the device attributes?
Here is the NotifyFullStatus event json and after that I have attached the json used when the device is being created.
So making good progress.
{ "src": "shellyplusht-<the_id>", "dst": "shellyplusht-<the_id>/events", "method": "NotifyFullStatus", "params": { "ts": 9.37, "ble": {}, "cloud": { "connected": false }, "devicepower:0": { "id": 0, "battery": { "V": 0.43, "percent": 0 }, "external": { "present": true } }, "ht_ui": {}, "humidity:0": { "id": 0, "rh": 54.2 }, "mqtt": { "connected": true }, "sys": { "mac": "<the_id>", "restart_required": false, "time": null, "unixtime": null, "uptime": 9, "ram_size": 246872, "ram_free": 167920, "fs_size": 458752, "fs_free": 176128, "cfg_rev": 11, "kvs_rev": 0, "webhook_rev": 0, "available_updates": {}, "wakeup_reason": { "boot": "deepsleep_wake", "cause": "status_update" }, "wakeup_period": 600 }, "temperature:0": { "id": 0, "tC": 24.8, "tF": 76.7 }, "wifi": { "sta_ip": "the_IP", "status": "got ip", "ssid": "the_SID", "rssi": -75 }, "ws": { "connected": false } } }
Device creation - topic "shelly-gen2-cmd/rpc":
{ "id": "table: 0x55a8a880e0", "src": "shellyplusht-<the_id>", "dst": "shelly-gen2-cmd", "result": { "ble": { "enable": false, "rpc": { "enable": true } }, "cloud": { "enable": false, "server": "iot.shelly.cloud:6012/jrpc" }, "devicepower:0": {}, "ht_ui": { "temperature_unit": "C" }, "humidity:0": { "id": 0, "name": null, "report_thr": 5, "offset": 0 }, "mqtt": { "enable": true, "server": "server_ip:1883", "client_id": "shellyplusht-<the_id>", "user": null, "topic_prefix": "shellyplusht-<the_id>", "rpc_ntf": true, "status_ntf": false, "use_client_cert": false, "enable_rpc": true, "enable_control": true }, "sys": { "device": { "name": null, "mac": "<the_id>", "fw_id": "20231106-160224/1.0.8-gdba0ee3", "discoverable": true }, "location": { "tz": "some-place", "lat": "lat", "lon": "lon" }, "debug": { "level": 2, "file_level": null, "mqtt": { "enable": false }, "websocket": { "enable": false }, "udp": { "addr": null } }, "ui_data": {}, "rpc_udp": { "dst_addr": null, "listen_port": null }, "sntp": { "server": "time.google.com" }, "cfg_rev": 11 }, "temperature:0": { "id": 0, "name": null, "report_thr_C": 0.5, "offset_C": 0 }, "wifi": { "ap": { "ssid": "ShellyPlusHT-<the_id>", "is_open": true, "enable": false }, "sta": { "ssid": "some_SID", "is_open": false, "enable": true, "ipv4mode": "dhcp", "ip": null, "netmask": null, "gw": null, "nameserver": null }, "sta1": { "ssid": null, "is_open": true, "enable": false, "ipv4mode": "dhcp", "ip": null, "netmask": null, "gw": null, "nameserver": null }, "roam": { "rssi_thr": -80, "interval": 60 } }, "ws": { "enable": false, "server": null, "ssl_ca": "ca.pem" } } }
-
-
None of this is needed for my config, but indeed I do have a static IP defined.
-
Edit : that didn't sound to good on 2nd read, so: yes I'm unsure why you would need an ip address, so not so concerning.
-
IP was used for HTTP request to get device name in an early version, and that piece of code remained.
The whole point of MQTT is that it doesn’t need one, of course.
Edit: It is, however, used to the browser window in the openLuup device page of the parent device, so that you can interact directly with the it for firmware updates, etc..
-
Try development latest version (v24.2.11).
Valid child readings should happen on next device update (ie. time interval or temperature/humidity significant change)
I've tested this with a DCHP configuration and it works OK.
-
Now working. Thank you. Will get back to you with a full report.
-
a-lurkerreplied to a-lurker on Feb 14, 2024, 6:04 AM last edited by a-lurker Feb 14, 2024, 1:24 AM
Working fine except for a couple of small points. In the earlier H&T device the battery topic is:
shellies/shellyht-<deviceid>/sensor/battery
In the newer device it's:
shellyplusht-<Device_ID>/status/devicepower:0
and returns:
{ "id": 0, "battery": { "V": 0.43, "percent": 0 }, "external": { "present": true } }
It would be good if "external" is true ie USB powered; that battery percent is set to 100% and the Voltage (variable V) to 5 Volts. ie USB Voltage. Any battery values are incorrect, as you are meant to remove the batteries, when running off USB power.
Interesting the battery percent in the UI dashboard for the parent device shows the value of "CurrentLevel" ie the actual humidity percentage measured. Not sure how that got in there! Looks like if the battery level is missing, something else gets plugged into there.
The service urn:micasaverde-com:serviedId:HumiditySensor1 service saves the humidity as "CurrentLevel". In the Historian rules this gets picked up as Current as in Amperes.
CurrentHumidityLevel would have been nice but that's MIOS.
-
Please try development latest version (v24.2.14) for power V and %.
Don't understand your comments on UI dashboard and Historian rules.
-
My wishes have been granted on the USB! The parent device shows the humidity % just to the right of the Shelley Icon. Not sure why the temperature is not there as well. Sounds like an AltUI thing. Sorry; got a bit confused between the battery percentage and the humidity, so ignore that. The v variable should be a capital V for Volts but that's my OCD again. So looking good. Thanks.
-
Oh, you’re looking at AltUI. I don’t even have that installed on my production system since everything configuration-related can be done with the openLuup console.
I agree with ‘V’, however the ‘v’ is a hangover from the native naming in earlier Shellies. It should probably be in a different service anyway.
-
Has anyone got a Shelly Plus Uni yet...?
...and done anything with it??I've just acquired a couple of them, and pleased to say that they're immediately recognised by the latest Shelly bridge in openLuup.
What's a bit missing from the Shelly site, AFAIK, is any decent instructions about device configuration. I'm planning to use these as pulse counters for utility meters (which Shelly do advertise as an application.)
-
Hope you are making progress withe the Shelly Plus Uni?
And any possibility of including the shelly pro 3em to the list of supported devices?
-
Yes, I’m looking at a more generic way of supporting Plus devices. Have you got one yet?
-
No - I don't have one at this time but I'll order one up, as I would very much like to make use of one. The Remote Procedure Calls (RPC) seems to be the new direction. On the H&T device, you have to enable some of the older topics (via a checkbox) to get it to work with the plugin.
I've been battling with Z-Wave JS of late. Looks like the ZWay plugin could be a good basis for communicating with that. ie swapping the http rx/tx over to MQTT. Sounds simple - right!!
-
OK - updates have been made to the Shelley plugin. All is still working OK here.
On the Shelly H&T device: AltUI shows (under unknown circumstances) in the UI of the parent device: Line 1 and line 2 show the temperature and humidity - that's good. However, at later times, it shows Line 1 and line 2 as the humidity and blank. Not sure if AltUi or openLuup is the issue.
I now have a "Shelly Pro 3em". If you are interested in integrating it, let me know how I help. I see at the other place, they are still having problems with this one!
-
Yes, I think one of the challenges with the 3em is the number of configurations it may be used in. Are you planning on three phase or single phase?
-
Good point. Single phase. Or is it just a case of making three meters?
-
You might just try firing up the device and point it to openLuup’s MQTT server. It should be detected, currently as a generic device, but updates from it should generate some device variables.
I can later add child devices of the right sort.
-
Will do.
-
akbooerreplied to a-lurker on Mar 24, 2024, 3:12 PM last edited by akbooer Mar 24, 2024, 11:13 AM
@a-lurker said in openLuup: Shelly Bridge plugin:
On the Shelly H&T device: AltUI shows (under unknown circumstances) in the UI of the parent device: Line 1 and line 2 show the temperature and humidity - that's good. However, at later times, it shows Line 1 and line 2 as the humidity and blank. Not sure if AltUi or openLuup is the issue.
Yes, I know this one. If a device has a standard Temperature or Humidity variable, then AltUI will display the value on the panel. Unfortunately, if it has both, then only the humidity is shown after the first update.