openweather plugin ?

[akbooer]

OK, so we’ll have to do this in an iterative way, with me making a few mistakes.

[akbooer]

@ArcherS

Just for you, I’ve bought one of my own. Hasn’t arrived yet, but I’ll be right on it when it does.

AK

[ArcherS]

@akbooer top notch service as always! Hopefully you will get good use of it also.
So far I am happy with mine. The dimmer supports all kind of switches. I use it with a spring loaded wall switch in "one button mode", i.e. as a push button with push-and-hold for dimming.

As a side note I am still on 1.9.x on my Shellies since I did not get mqtt to work with the new firmware. On the EU Shelly support site it is very easy to set up an ota-url for flashing older versions on a device.

[akbooer]

@therealdb

I missed your post, somehow. As you see, I’ve gone for the hardware rather than a virtual solution, but I certainly won’t be doing that for all new Shellies!

Any details to share on how you’ve done this?

[therealdb]

@akbooer I just wrote a super simple http server replying the same way Shelly devices are doing. Plus, I send mqtt messages every x secs to my dev mqtt broker, to replicate the same behavior. I was using this while developing the support for mqtt inside my own system.

I’ve done the same way for opensprinkler, in order to avoid messing with my sprinklers.

It’s done in C#, but it should be easy with anything else.

[Buxton]

@akbooer is there any chance on you decoupling the tasmota and shelly bridges from openLuup. I'm asking because if the bridges were stand alone plugins, they could be used as quasi templates for other MQTT devices. For example, my BlueIris server MQTT messaging now maps to individual Vera devices that represent BlueIris cameras (created with the Tasmota bridge), but the functionality of each vera device is limited, due to the way in which the tasmota bridge creates its child devices. With a stand alone plugin, I could revise a clone of the plugin to include more specific functionality for a given MQTT source.

Everything MQTT wise works well now, so no real need to do this, but it strikes me that it would be a cleaner approach to handling MQTT in openLuup and the myriad IOT devices that will make use of the protocol.

[akbooer]

They're closely coupled so that they can auto-install if any of their devices are detected, rather than having to download a bridge plugin separately. As such, I consider them to be an integral part of the system (a change, certainly, from my previous device-agnostic approach, but part of my personal move away from ZWave.)

The MQTT bridge functionality is totally general, and I would have thought that this was a better place to start.

...or am I missing your point, here?

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

@akbooer top notch service as always! Hopefully you will get good use of it also.

Well, we'll see (the device arrived yesterday)...

Latest development version of openLuup (v21.11.2) has an initial attempt to service the Dimmer2 device:

• inputs are handled exactly as the switch device – so, essentially, as a scene controller showing the latest activated scene: short press; long press; etc... This should work for both input switches (if you have any with two.)
• on/off button on the control panel should work for the dimmer bulb.
• slider control is not yet implemented.

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.

So I'd appreciate a listing of any bugs that you find, and I'll continue to work on the slider control.

Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.

[Buxton]

@akbooer It's just easier to understand the code/ what's occurring in a plugin as opposed to openLuup, mainly because of the typical plugin structure and its place on top of the openLuup subsystem. That's probably a trivial distinction to you, but for me it's a huge difference in understanding as I'm not in any way fluent with the inside baseball of the OLuup object model.

Per your MQTT comment, though it can be done (https://github.com/jziolkowski/tdm), it would be difficult to have functional device bridges if you took away MQTT, as you'd have to interrogate a router in some fashion to find out if these devices exist on one's network, and then use http commands to control the devices. So I see MQTT handling as more an innate part of the OL subsystem, like http, than a device profile like tasmota or shelly, device profiles that are typically handled as stand alone plugins.

[ArcherS]

@akbooer said in openLuup: Shelly Bridge plugin:

Well, we'll see (the device arrived yesterday)...
Latest development version of openLuup (v21.11.2) has an initial attempt to service the Dimmer2 device:

inputs are handled exactly as the switch device – so, essentially, as a scene controller showing the latest activated scene: short press; long press; etc... This should work for both input switches (if you have any with two.)
on/off button on the control panel should work for the dimmer bulb.
slider control is not yet implemented.

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.
So I'd appreciate a listing of any bugs that you find, and I'll continue to work on the slider control.
Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.

@akbooer thank you for the effort, I installed v21.11.2 and have tested this a bit.

For a start I have my switch connected to "sw 1". It is a single button switch, defined as a "one button mode" in the Shelly GUI.
"sw 1" seems to report as "light/0" in the Mqtt message.

It does not work fully in OpenLuup yet, below I list what I have found.

Turning on/off with the physical switch:

• The status in AltUI does change when turning the light on and off.

• When I turn the light "off" with the physical switch I have:
  light/0:
  off
  light/0/status: {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}

• When I turn the light "on" with the physical switch (at 80%) I have:
  light/0:
  on
  light/0/status:
  {"ison":true,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}

Turning the light on/off in AltUI:

• The light does not turn on/off when I turn it on/off in AltUI.

• When I turn it "on" in AltUI I have:
  light/0:
  off
  light/0/status:
  {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}
  relay/0/command:
  on

• When I turn it "off" in AltUI I have:
  light/0:
  off
  light/0/status:
  {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}
  relay/0/command:
  off

When I turn it "on" in AltUI it looks like this:

When I turn on the light with the physical switch it looks like this:

In Mqtt Explorer I have the following:
Light on (i.e. turned on with the physical switch):

Light off (i.e. turned off with the physical switch):

Turning on in AltUI (but light off):

Turning off in AltUI (light still off):

The "relay/0/command" command that is sent from AltUI does in other words not to give any effect on the Shelly device. In fact with a fresh Mqtt Explorer session it only emerges when turning on/off in AltUI.

Hopefully this gives some hints to what is wrong. Let me know if you need more information.

@akbooer said in openLuup: Shelly Bridge plugin:

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.

Dimmable LED lights are a bit tricky still. Some of them work and some of then do not work very well. It can be a bit of a pain to find good ones. The upside is that the Shelly dimmer can be changed from trailing and leading edge dimming (under "Calibration"). This should hopefully mean that it can be a little bit better to adapt to different lights.

@akbooer said in openLuup: Shelly Bridge plugin:

Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.

Excellent news that the latest FW seems to work, I will test it later on one of my devices.

[akbooer]

More than enough to be going on with! Brilliant. Thanks.

[akbooer]

@ArcherS

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.

[ArcherS]

@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.

[akbooer]

Yes, that’s really weird, isn’t it?

I must try harder…

[therealdb]

@akbooer if I remember correctly, I’ve experienced something similar while developing my virtual Dimmer and this should be related to target/status variables (in this case loadleveltarget).

[akbooer]

@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.

[a-lurker]

@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}: 0x559e2a9768

Looks 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 first

As 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.

[akbooer]

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

[a-lurker]

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.

[akbooer]

Ah! My mistake. I will fix that. Thanks.

As you say, though, that’s not the issue here.