openweather plugin ?

[akbooer]

No, don't try that yet. I need to think rather than just react. I reboot all the time and the Shellies just keep on working.

[Elcid]

I was thinking that the bridge may be starting a new clean session when open luup reconnects after a reload, maybe that's an issue.

[akbooer]

This setting should make no difference to the openLuup MQTT server, since it keeps noothing but the basic session info. However, it may make a difference to Mosquitto.

[Elcid]

OK Mosquitto reports bridge disconnect and 5 seconds later reconnects, when i reload luup.

I then power off 1 device and back on, Mosquitto reports device already connected,closing connection then new client shelly device and ip.

back in AltUI the device i power cycled is working , all other still not.

[akbooer]

It seems that this is related to the CLEAN SESSION flag. Can you configure Mosquitto to set that flag?

[Elcid]

Tried that last night both cleansession false and ture, no effect

I have posted the issue in the Eclypse forum.

[therealdb]

Here's what I found with my Shellies (more to come, I have a couple more on the test bench, not already connected).

• Shelly 1PM seems OK. Ext temperatures are not mapped, but the variable is crated:
  This should be easily mapped. I don't have humidity attached, but it's similar, looking at the docs.
• Shelly plug is not correctly mapped. Here's the announce payload:

{"id":"shelly-veraplug","model":"SHPLG-S","mac":"XXX","ip":"192.168.1.46","new_fw":true,"fw_ver":"20210323-105718/v1.10.1-gf276b51"}

It's mapped as a scene control, instead of a plug. Power variables are correctly saved.

As I've said, I have buttons, uni and EM on my test bench and I'll add them very soon, so I could help with code if necessary @akbooer .

[akbooer]

@therealdb

Try v21.4.18 to see if the plug now works (it will create a separate child device.)

[therealdb]

@akbooer all set now for shelly plug!

EDIT: I think category_num and subcategory_num should be set to at least 3/0, so the UI could filter them better.

So, the recommendation for Shelly 1 PM used as detached relay (input separated from relay) is to manually use the variables?

[akbooer]

Good news on the plug. I haven't yet considered setting the (sub)category automatically, but it should be easy enough.

For any Shelly with switches, the generic device has the raw variables but also they're treated as a scene controller, so you have sl_SceneActivated and LastSceneTime available to you.

[ArcherS]

@akbooer I have a Shelly Plug (not the "S" variant) that I now finally setup on my test Pi to try the Shelly bridge.

The plug shows as it should in the Shellies room:

The following variables are mapped:

The payload is:

{"id":"shellyplug-6CC126","model":"SHPLG2-1","mac":"xxx","ip":"192.168.1.30","new_fw":false,"fw_ver":"20201124-092420/v1.9.0@57ac4ad8"}

However no child devices show up for the plug what I can see.
Is this something that can be added to the bridge, or have I missed anything in my setup?

(running OpenLuup v 21.4.18)

[therealdb]

@archers it needs to be mapped. If you go to line 416 of the Shelly bridge, you should be able to adapt it quickly, while @akbooer is busy coding it.

[akbooer]

Version 21.4.25 has the addition!

[ArcherS]

@akbooer that seems to have worked, now I get the child device and can control the plug on/off, thanks!

[ArcherS]

@akbooer now on to my second Shelly, a Shelly Uni.

Same thing here, I assume, no child devices are created some mapping is required.
(For my Uni I have the two relays connected to two relays reading two states from the alarm, and no buttons connected to control the two inputs. In other words in my application I do not really need the input child devices.)

It gets created as it should:

Variables:

The temperature gets mapped correctly.
The two "relay" variables are the outputs for each channel are also as they should from what I can see.

Payload:

{"id":"shellyuni-483FDA82C252","model":"SHUNI-1","mac":"xxx","ip":"192.168.1.31","new_fw":false,"fw_ver":"20201124-093042/v1.9.0@57ac4ad8"}

I think the "input" variables are the two buttons that you can control as a user that need child devices.

If I remember it correctly @therealdb also has a Uni if you need more input from a second use case.

[therealdb]

@archers said in openLuup: Shelly Bridge plugin:

If I remember it correctly @therealdb also has a Uni if you need more input from a second use case

I literally have bought anything from them, but I've not fully deployed every device. I'm still waiting for my Uni and EM to be inserted. the EMs will soon monitor my AC, so I could detect if it's running or not (I have to use two switchbots to turn it on/off, because it's still under warranty and I could not mess with the original thermostat).

All that said, I'm voting for automatic creation of child temp/humidity sensors, and for Uni to create relays and inputs separately. That's what most people will do, anyway.

[ArcherS]

@therealdb said in openLuup: Shelly Bridge plugin:

I literally have bought anything from them, but I've not fully deployed every device. I'm still waiting for my Uni and EM to be inserted. the EMs will soon monitor my AC, so I could detect if it's running or not (I have to use two switchbots to turn it on/off, because it's still under warranty and I could not mess with the original thermostat).

@therealdb I still have an EM that I will setup over time to monitor the consumption of the spa and the HVAC.
I also have a few more Shellies inbound in the mail; some Shelly 1's, a few 1PMs and a Button1. The plan is to replace a few aeging Aeotec relays that do not behave properly with the 1PMs.
The Button1 I plan to use instead of a really old Zwave.me wall controller.

All that said, I'm voting for automatic creation of child temp/humidity sensors, and for Uni to create relays and inputs separately. That's what most people will do, anyway.

I can second the thought on autocreation of temp/humidity and relay/input for the Uni if it is feasible to maintain. However not being a developer I am happy with what I get!

The native Shelly and Tasmota support in OpenLuup together with the Mqtt support is a huge and really cool addition to the platform!

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

The Button1 I plan to use instead of a really old Zwave.me wall controller.

Yup, done that too. OK if you can get used to the 2 second delay (unless on USB power.)

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

I can second the thought on autocreation of temp/humidity and relay/input for the Uni if it is feasible to maintain.

Not, fundamentally, any problem, but I haven’t (yet) got a Uni.

[ArcherS]

@akbooer said in openLuup: Shelly Bridge plugin:

Yup, done that too. OK if you can get used to the 2 second delay (unless on USB power.)

I have now included the Button1 and it works ok, it added without problems in OpenLuup. No child devices, but I assume that is the way it should be.

I think I will keep it attached to USB power. I have power available where the button is located and this gives more or less instant actions. I also noticed that if it is not on USB in some cases it does not connect as it should when going out of sleep when you push the button.
I assume that wifi is not the best technology for battery powered devices.
So far I am using a direct action from the button to the 1PM that it should control.