openLuup: Shelly Bridge plugin
-
So device #46 is your Shelly bridge?
Which polling frequency were you thinking of?
-
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 %
-
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.
-
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
-
Yes, I think it uses half the keep-alive time.
-
Elcidreplied to akbooer on Apr 16, 2021, 5:37 PM last edited by Elcid Apr 16, 2021, 2:41 PM
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
-
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% -
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.
-
Yep, using device 30005 a binary type device
-
Can you post the content of one of its status messages, so that I can reproduce the problem?
-
subscribing to shellies/shelly1-93FC56/relay/0
"off" or "on"
depeding on the switch position -
Ah, no, sorry. I meant specifically the announce message (first one after bridge starts up.)
-
It's so hard to debug without the actual hardware. So the Shelly device itself does respond to the SetTarget, but the openLuup device doesn't update its status?
-
I totally understand the difficulty with out the device.
The variable target now updates to 1 or 0 depending if switch is on or off.
so
device state off and icon off
press on icon, icon flashes to on then back to off, the variable target updates to 1. Device does not respond
press icon again this time icon stay on, variable target stays at 1 . The devices does not respond.
press icon again this time icon stays at off, variable target updates to 0. The device does not respond.Status never changes form 0
when subscribed to shellies/shelly1-93FC56/rely/0
no messages are received when icon is pressed. -
@Elcid
I'm trying a different approach. Please delete any Shelly-1 devices and then update to 21.4.17b. This will force each Shelly-1 to have a parent device (of generic Shelly type) and a child device (binary light). Actions on the binary light should now work as expected, but, once again, I can't easily test it myself. -
Bingo. That did it the devices now have a master and a slave and respond to actions.
Will setting the master invisible have any bad effects?
17/144