openweather plugin ?

[akbooer]

Feedback / solutions with openLuup's built-in Shelly bridge.

[a-lurker]

Mmm looked high and low for the Shelly bridge and can find no mention of it. Using openLuup ver 2021.03.01b. What's the trick?

[rafale77]

That's odd, I am running 2021.02.20 and had mine show up once I upgraded even though I did not setup anything for it. Maybe you need to enable the MQTT server?

[akbooer]

@a-lurker you need to enable the MQTT server and also the Shelly’s use of MQTT. Bridge is then created automatically.

@rafale77 this is now fixed. Update to latest and delete the plugin device.

[Elcid]

@akbooer
Just playing and adding some shelly 1's the bridged mqtt server finds the devices and the switch and relay variable update, all good there. Just have to ask are the set target actions and status implemented? As the status never updates.

[akbooer]

Hmm... should be. Both SetTarget and ToggleState actions are implemented.

I haven't got any Shelly 1s but it works for the 2.5.

[Elcid]

@akbooer
Here is the returned error

and when i toggle button on altui device i get this in log but no response on physical device.

2021-04-16 17:35:07.971   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=587647848&Timeout=60&MinimumDelay=1500&_=1618590331394 HTTP/1.1 tcp{client}: 0xf3280b98
2021-04-16 17:35:12.250   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=30005&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0xf32afcf8
2021-04-16 17:35:12.254   luup.call_action:: 30005.urn:upnp-org:serviceId:SwitchPower1.SetTarget 
2021-04-16 17:35:12.255   luup.call_action:: action will be handled by parent: 46
2021-04-16 17:35:12.256   openLuup.server:: request completed (44 bytes, 1 chunks, 3 ms) tcp{client}: 0xf32afcf8
2021-04-16 17:35:14.492   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=30005&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0 HTTP/1.1 tcp{client}: 0xf32afcf8
2021-04-16 17:35:14.495   luup.call_action:: 30005.urn:upnp-org:serviceId:SwitchPower1.SetTarget 
2021-04-16 17:35:14.497   luup.call_action:: action will be handled by parent: 46
2021-04-16 17:35:14.499   openLuup.server:: request completed (44 bytes, 1 chunks, 5 ms) tcp{client}: 0xf32afcf8
2021-04-16 17:35:15.497   openLuup.server:: request completed (3627 bytes, 1 chunks, 7566 ms) tcp{client}: 0xf345b938
2021-04-16 17:35:15.508   openLuup.server:: request completed (3627 bytes, 1 chunks, 7535 ms) tcp{client}: 0xf3280b98
2021-04-16 17:35:15.511   openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0xf345b938
2021-04-16 17:35:15.519   openLuup.io.server:: HTTP:3480 connection from 192.168.1.10 tcp{client}: 0xf38161e8
2021-04-16 17:35:15.526   openLuup.server:: GET /data_request?id=status&DataVersion=587647852&Timeout=15&MinimumDelay=100&output_format=json&_r=1618590915513 HTTP/1.1 tcp{client}: 0xf38161e8
2021-04-16 17:35:15.651   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=587647852&Timeout=60&MinimumDelay=1500&_=1618590331395 HTTP/1.1 tcp{client}: 0xf3280b98
2021-04-16 17:35:20.890   openLuup.server:: GET /openLuup?page=log HTTP/1.1 tcp{client}: 0xf32afcf8

Does the fact that the devices are set to a broker that is bridged to openLuup have any bearing

P.S. where can we change the polling fequency?

[akbooer]

So device #46 is your Shelly bridge?

Which polling frequency were you thinking of?

[Elcid]

The devices seem to be updating in reactor(MSR) every 30 seconds, but there has been no actions in that time, they just seem very chatty

Yes 46 is the shelly bridge

[edit] also noting that openLuup cpu has gone from 0.6 - 1% to 3 - 3.8 %

[akbooer]

Oh, you mean the Shelly devices themselves. This is on each individual Shelly device and related to :

Internet & Security > ADVANCED - DEVELOPER SETTINGS > MQTT > Keep Alive.

...but I'm not sure. I you make this longer, it will take londer for your devices to be discovered initially (but that doesn't really matter.) Updates should be effectively instant.

Edit: that increase in CPU doen't seem right. I can barely detect any difference... unless you are subscribed to everything (with, for example MQTT Explorer.) Even then it should be minimal.

[Elcid]

Strange keep alive is set to 60s and the updates are every 30

the only thing subscribed to openLuup is the mosquitto broker with #, all devices are subscribed to mosquitto

[akbooer]

Yes, I think it uses half the keep-alive time.

[akbooer]

@Elcid

Can I see the openLuup device variable page for the Shelly device in question?

[Elcid]

@akbooer

HaDevice1		CommFailure	
0
HaDevice1		Configured	
0
HaDevice1		LastUpdate	
2021-04-16 18:30:58
HaDevice1		PollMinDelay	
60
HaDevice1	history graph	PollingEnabled	
0
SwitchPower1		Status	
0
SwitchPower1		Target	
0
93FC56		announce	
{"id":"shelly1-93FC56","model":"SHSW-1","mac":"BCDDC293FC56","ip":"192.168.1.100","new_fw":true,"fw...
93FC56		input/0	
0
93FC56		input_event/0	
{"event":"","event_cnt":0}
93FC56		online	
true
93FC56		relay/0	
off

[Elcid]

The cpu usage seems to be MSR. I linked MSR to openLuup at same time I added shelly 1's.
CPU now at 0.8%

[akbooer]

Good news re. CPU.

On the action call, are you using the right device? There should be a child device which is a binary light, rather than the device with the Shelly icon.

[Elcid]

Yep, using device 30005 a binary type device

[akbooer]

Can you post the content of one of its status messages, so that I can reproduce the problem?

[Elcid]

subscribing to shellies/shelly1-93FC56/relay/0
"off" or "on"
depeding on the switch position

[akbooer]

Ah, no, sorry. I meant specifically the announce message (first one after bridge starts up.)