openLuup: Shelly Bridge plugin
-
Can you give latest development (v21.11.8) a try?
I don't think I'm quite there yet, but the dimmer control should work to some extent.
This is surprisingly hard, since the status/control aspect of the Shelly dimmer is not quite the same as that of a ZWave one... I've always hated the way that Vera handled dimmers anyway! But I'm doing the best I can.
-
@akbooer said in openLuup: Shelly Bridge plugin:
Can you give latest development (v21.11.8) a try?
I don't think I'm quite there yet, but the dimmer control should work to some extent.
This is surprisingly hard, since the status/control aspect of the Shelly dimmer is not quite the same as that of a ZWave one... I've always hated the way that Vera handled dimmers anyway! But I'm doing the best I can.I installed v21.11.8 and now it almost seem to work.
In short what is not entirely in place is that the dimmer slider on the AltUI desktop in some cases does not follow the set value.
Example:
When I change the dim value in the Shelly GUI it updates in OpenLuup inside the dimmer but the slider on the desktop does not update.Starting with the dimmer off and all sliders on 1% and then dim to 40% on the Shelly GUI gives:
In the Shelly GUI:
On the desktop in AltUI:
Inside the dimmer controller in AltUI:
Variables:
light/0/status:
{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":40}If I instead change the dim value from AltUI either from inside the dimmer controller or from the desktop it works and everything is updated. Also the slider inside the AltUI dimmer seems to work as it should.
Let me know if you need more information.
Based on your input I tested the latest fw (v1.11.4) on a Shelly Plug and it does indeed seem to work with Mqtt. Great news that it actually works now.
-
@therealdb said in openLuup: Shelly Bridge plugin:
this should be related to target/status variables (in this case loadleveltarget).
Thanks, yes, indeed it's something like that.
The curious this is that the AltUI dimmer controls work differently from each other, so this rather looks like a 'feature' of AltUI.
As far as I can tell from the openLuup side of things, it's working as it should. The nasty hack is to allow the status to override the target, but that brings other side-effects. It's usually more of an issue if there is a slow ramp involved too.
I hate dimmers.
-
@akbooer It's been awhile but I thought I would try out a gen2 Shelly Plus H&T. It's a nice looking device.
The openLuup Shelley bridge has some initial support for Gen2 devices but I encountered quite a few show stoppers. The gen2 devices use different topics and Remote Procedure Calls (RPC) seem to be the new direction. I can go into that further but I thought this would be a starting point:
With the log below; openLuup and the Shelly don't know about each other as yet and I get this RX error every time the Shelly publishes an event. I have no idea why. The Shelley device spits out event info unprompted, as it lets the world know of its status. I see this in MQTT explorer:
openLuup zigbee2mqtt $SYS shellyplusht-80646fc9b46d online = true events rpc = { "src": "shellyplusht-80646fc9b46d", "dst": "shellyplusht-80646fc9b46d/events", "method": "NotifyFullStatus", "params": { "ts": 1.49, "ble": {}, "cloud": { "connected": false }, "devicepower:0": { "id": 0, "battery": { "V": 0.43, "percent": 0 }, "external": { "present": true } }, "ht_ui": {}, "humidity:0": { "id": 0, "rh": 51.8 }, "mqtt": { "connected": true }, "sys": { "mac": "<mac address>", "restart_required": false, "time": null, "unixtime": null, "uptime": 1, "ram_size": 246868, "ram_free": 167952, "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": 21.9, "tF": 71.5 }, "wifi": { "sta_ip": "<ip address>", "status": "got ip", "ssid": "<sid>", "rssi": -67 }, "ws": { "connected": false } } }And the log looks like this:
2023-12-20 13:32:14.259 openLuup.io.server:: MQTT:1883 connection from <ip address> tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.261 openLuup.mqtt:: CONNECT tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.261 openLuup.mqtt:: ClientId: shellyplusht-80646fc9b46d 2023-12-20 13:32:14.261 openLuup.mqtt:: WillTopic: shellyplusht-80646fc9b46d/online 2023-12-20 13:32:14.261 openLuup.mqtt:: WillMessage: false 2023-12-20 13:32:14.261 openLuup.mqtt:: UserName: **** 2023-12-20 13:32:14.261 openLuup.mqtt:: Password: **** 2023-12-20 13:32:14.262 openLuup.mqtt:: CONNACK ack 2023-12-20 13:32:14.273 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.273 openLuup.mqtt:: Packet Id: 0x0001 2023-12-20 13:32:14.273 openLuup.mqtt:: Topic: shellyplusht-80646fc9b46d/rpc 2023-12-20 13:32:14.273 openLuup.mqtt:: SUBACK ack 2023-12-20 13:32:14.274 openLuup.mqtt:: shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/rpc tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.279 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.279 openLuup.mqtt:: Packet Id: 0x0002 2023-12-20 13:32:14.279 openLuup.mqtt:: Topic: shellyplusht-80646fc9b46d/command/sys 2023-12-20 13:32:14.280 openLuup.mqtt:: SUBACK ack 2023-12-20 13:32:14.280 openLuup.mqtt:: shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/command/sys tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.282 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.282 openLuup.mqtt:: Packet Id: 0x0003 2023-12-20 13:32:14.282 openLuup.mqtt:: Topic: shellyplusht-80646fc9b46d/command 2023-12-20 13:32:14.282 openLuup.mqtt:: SUBACK ack 2023-12-20 13:32:14.283 openLuup.mqtt:: shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/command tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.285 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.285 openLuup.mqtt:: Packet Id: 0x0004 2023-12-20 13:32:14.285 openLuup.mqtt:: Topic: shellies/command 2023-12-20 13:32:14.285 openLuup.mqtt:: SUBACK ack 2023-12-20 13:32:14.285 openLuup.mqtt:: shellyplusht-80646fc9b46d SUBSCRIBE to shellies/command tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.287 openLuup.mqtt:: PUBLISH tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.288 openLuup.mqtt:: PUBACK ack 2023-12-20 13:32:14.290 openLuup.mqtt:: PUBLISH tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.290 openLuup.mqtt:: PUBACK ack 2023-12-20 13:32:14.293 openLuup.mqtt:: PUBLISH tcp{client}: 0x559e2a9768 2023-12-20 13:32:14.293 openLuup.mqtt:: PUBACK ack 2023-12-20 13:32:16.280 openLuup.mqtt:: PUBLISH tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.281 openLuup.mqtt:: PUBACK ack 2023-12-20 13:32:16.775 openLuup.io.server:: MQTT:1883 connection closed tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.775 openLuup.mqtt:: RECEIVE ERROR: (Fixed Header byte) closed tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.775 openLuup.mqtt:: shellyplusht-80646fc9b46d UNSUBSCRIBE from shellyplusht-80646fc9b46d/rpc tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.776 openLuup.mqtt:: shellyplusht-80646fc9b46d UNSUBSCRIBE from shellyplusht-80646fc9b46d/command tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.776 openLuup.mqtt:: shellyplusht-80646fc9b46d UNSUBSCRIBE from shellyplusht-80646fc9b46d/command/sys tcp{client}: 0x559e2a9768 2023-12-20 13:32:16.776 openLuup.mqtt:: shellyplusht-80646fc9b46d UNSUBSCRIBE from shellies/command tcp{client}: 0x559e2a9768Looks like openLuup is expecting more but the Shelley device is all done?
I looked around mqtt.lua but the only thing that I thought may be incorrect is line 201:
for i = 0, 2 do -- maximum of 3 bytes encode remaining length, LSB firstAs I understand it, the protocol is 4 bytes here, not three, so the for loop is short by one. However, this wouldn't be found out, unless your mqtt message was more than 2 megabytes long, so not likely to be encountered any time soon.
-
Thanks for the error report. Not surprising, since, as you say, there is only limited support for the new Shellys. I've just added them on an as-needed basis, and I don't have that device (looks interesting, though!)
@a-lurker said in openLuup: Shelly Bridge plugin:
I looked around mqtt.lua but the only thing that I thought may be incorrect is line 201:
for i = 0, 2 do -- maximum of 3 bytes encode remaining length, LSB first
No, this is not an error. The initial fixed-header byte is picked up in line 196:
local fixed_header_byte1, err = client: receive (1)I'll look into this further and get back to you.
AK
-
You have fixed_header_byte1, which is essential and nothing would work with out it but the subsequent message length encoding is a four byte concertina arrangement, not a three byte one.
-
Ah! My mistake. I will fix that. Thanks.
As you say, though, that’s not the issue here.
-
The error seems odd, since the receive function is only called from the incoming handler when there is data to read...
I'm perplexed.
-
I added a one line of logging after line 296 & 297 like so:
function MQTT_packet.PUBLISH (TopicName, ApplicationMessage, control_flags) -- publish to MQTT client socket (with QoS = 0) _log ('Topic: '..TopicName..' ApplicationMessage: '..ApplicationMessage)and here is the log edited to show the action:
CONNECT tcp{client}: 0x55a8931288 ClientId: shellyplusht-80646fc9b46d WillTopic: shellyplusht-80646fc9b46d/online WillMessage: false UserName: **** Password: **** CONNACK ack SUBSCRIBE tcp{client}: 0x55a8931288 Packet Id: 0x0001 Topic: shellyplusht-80646fc9b46d/rpc SUBACK ack shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/rpc tcp{client}: 0x55a8931288 SUBSCRIBE tcp{client}: 0x55a8931288 Packet Id: 0x0002 Topic: shellyplusht-80646fc9b46d/command/sys SUBACK ack shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/command/sys tcp{client}: 0x55a8931288 SUBSCRIBE tcp{client}: 0x55a8931288 Packet Id: 0x0003 Topic: shellyplusht-80646fc9b46d/command SUBACK ack shellyplusht-80646fc9b46d SUBSCRIBE to shellyplusht-80646fc9b46d/command tcp{client}: 0x55a8931288 SUBSCRIBE tcp{client}: 0x55a8931288 Packet Id: 0x0004 Topic: shellies/command SUBACK ack shellyplusht-80646fc9b46d SUBSCRIBE to shellies/command tcp{client}: 0x559c9277e8 PUBLISH tcp{client}: 0x559c9277e8 PUBACK ack Topic: shellyplusht-80646fc9b46d/online ApplicationMessage: true Topic: shellyplusht-80646fc9b46d/online ApplicationMessage: true PUBLISH tcp{client}: 0x559c9277e8 PUBACK ack Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyFullStatus","params":{"ts":1.45,"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.7},"mqtt":{"connected":true},"sys":{"mac":"80646fc9b46d","restart_required":false,"time":null,"unixtime":null,"uptime":1,"ram_size":246864,"ram_free":167876,"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":23.2, "tF":73.7},"wifi":{"sta_ip":"<ip_address>","status":"got ip","ssid":"<ssid>","rssi":-66},"ws":{"connected":false}}} Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyFullStatus","params":{"ts":1.45,"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.7},"mqtt":{"connected":true},"sys":{"mac":"80646fc9b46d","restart_required":false,"time":null,"unixtime":null,"uptime":1,"ram_size":246864,"ram_free":167876,"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":23.2, "tF":73.7},"wifi":{"sta_ip":"<ip_address>","status":"got ip","ssid":"<ssid>","rssi":-66},"ws":{"connected":false}}} PUBLISH tcp{client}: 0x559c9277e8 PUBACK ack Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyStatus","params":{"ts":1.45,"mqtt":{"connected":true}}} Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyStatus","params":{"ts":1.45,"mqtt":{"connected":true}}} PUBLISH tcp{client}: 0x559c9277e8 PUBACK ack Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyEvent","params":{"ts":1703301404.25,"events":[{"component":"sys", "event":"sleep", "ts":1703301404.25}]}} Topic: shellyplusht-80646fc9b46d/events/rpc ApplicationMessage: {"src":"shellyplusht-80646fc9b46d","dst":"shellyplusht-80646fc9b46d/events","method":"NotifyEvent","params":{"ts":1703301404.25,"events":[{"component":"sys", "event":"sleep", "ts":1703301404.25}]}} MQTT:1883 connection closed tcp{client}: 0x559c9277e8 openLuup.mqtt:: RECEIVE ERROR: (Fixed Header byte) closed tcp{client}: 0x559c9277e8Every 5 minutes the Shelly come on line, sends some status and finally sends the sleep mode event then goes into sleep mode. This would close the connection to the openLuup server. So I'm wondering if openLuup is checking for a "PUBACK" at this time and that's an issue? Might also be a QoS level mix up as well; eg "PUBACK" is not needed. Or the Shelly is going to sleep too early.
I'm still trying to understand how this all works and in what direction information is being sent eg is "PUBACK" been sent or received by openLuup. A few <-- arrows might be good --> eg incoming and outgoing.
And why does my log code line, log the same information twice in a row. I see it does this also for my Zigbee MQTT devices, which work fine. If openLupp is publishing one of its own internal variables the log only shows it once.
-
Good diagnostics! I will dig in (although it IS the holidays, so time for this is somewhat limited...)
-
What - you aren't around on Xmas day?
-
I obviously need to get one of these myself… but the UK store is currently out of stock.
-
Yes - they are a nice unit. The large display is easy to read. This guy does a good rant on the Shelley MQTT info.
I also got one of these zigbee devices: Aqara temperature, humidity, TVOC air quality monitor. The latter has smaller display than the Shelley. Both devices give very similar temperature readings but a substantial 10% difference in the humidity readings. I can't be certain but it looks like the zigbee device is less likely to be showing the correct figure. You can add offsets, etc but not too sure how you would actually go about calibrating it.
-
Yes, I’ve found significant humidity variation between different devices in the past. It’s a much harder measurement to make accurately than temperature.
-
I see that Shelly have now come out with Gen 3 devices, which may explain why there are none of the old ones available now.
-
Well I compared another Xiaomi humidity temperature device with the Shelley device and got a good match in the readings. It looks like the Shelly device and this particular Xiaomi device are literally out by the old software error factor of one ie a 10% difference. There is an OTA software update available but I can't get it to happen.
Anyway I got one of the hairs off my head and proceeded to calibrate it against the Shelly and the Xiaomi devices. I searched & searched and could only find a hair about 2 mm long. Complete waste of time. Maybe alopecia has set in?
Great to see the Gen3 device ( they've shrunk the kids once again) - looks like you have your work cut out for you re: openLuup. About a year from now; we'll get to see them on sale here where I live.
-
Shelly Plus H&T now back in stock, so I've ordered one.
-
Good news and I still haven't forgotten about Zwave via MQTT! Starting point, at a minimum, would be:
- light on/off (although most are dimmers these days, but not all)
- blinds up/down - pretty much the same as the above
- general purpose outlets (GPO) - pretty much the same as the above
- minimotes
Some items may be returning power consumption info as well.
The above would cover the majority of stuff?
