openweather plugin ?

[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.)

[Elcid]

@akbooer
Ok,sorry again for the image, this stupid app will not allow copy of text, I will have to look for another

[akbooer]

@Elcid

OK, that's great, exactly what I needed. The latest development version v21.4.17 should have fixed this.

[Elcid]

@akbooer
Have installed the latest, seems set target is working but the device does not respond and status is still 0

The action sends and gets an OK response

[akbooer]

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?

[Elcid]

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.

[akbooer]

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

[Elcid]

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?

[akbooer]

No, shouldn't matter at all.

[akbooer]

...or just put them in a different room.

[Elcid]

@akbooer
Seems a luup reload breaks the devices, only way to get them back is to delete them and restart Mosquitto.

[akbooer]

@elcid said in openLuup: Shelly Bridge plugin:

Seems a luup reload breaks the devices

Can you exapnd on that?

You mean that they work in the session that they are created, but do a restart and they don't work (but are still there) ??

[Elcid]

Yes. Noticed they stopped earlier so deleted and reloaded, nothing happened untill I restarted Mosquitto. So I kept an eye on them to see if they stopped again.

Then about 20 mins ago I was messing with the Tasmota's, so I did a reload and after that the shelly 1 stopped working (devices still in ui). So deleted them again and restart Mosquitto and then they reloaded.

[akbooer]

I'm not seeing this, but, then again, I've not bridged to Mosquitto. What happens if you just restart Mosquitto? Is there anything shown in the log?

[Elcid]

Restarting mosquitto this is in log

2021-04-17 20:59:14.986   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=687035184&Timeout=60&MinimumDelay=1500&_=1618687270165 HTTP/1.1 tcp{client}: 0xf5619c8
2021-04-17 20:59:21.613   openLuup.io.server:: MQTT:1884 connection closed  tcp{client}: 0xfc60a48
2021-04-17 20:59:21.614   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0xfc60a48
2021-04-17 20:59:21.616   openLuup.mqtt:: localhost.bridge-01 UNSUBSCRIBE from # tcp{client}: 0xfc60a48
2021-04-17 20:59:27.984   openLuup.io.server:: MQTT:1884 connection from 192.168.1.25 tcp{client}: 0xf096c288
2021-04-17 20:59:28.031   openLuup.mqtt:: localhost.bridge-01 SUBSCRIBE to # tcp{client}: 0xf096c288
2021-04-17 20:59:28.033   luup.variable_set:: 30001.shellyix3-front.online was: EMPTY now: true #hooks:0
2021-04-17 20:59:28.036   luup.variable_set:: 30007.shelly1-93BEFE.online was: EMPTY now: true #hooks:0
2021-04-17 20:59:28.056   luup.variable_set:: 30002.shelly1-93A847.online was: EMPTY now: true #hooks:0
2021-04-17 20:59:28.068   luup.variable_set:: 30005.shelly1-93FC56.online was: EMPTY now: true #hooks:0
2021-04-17 20:59:28.384   openLuup.server:: request completed (4780 bytes, 1 chunks, 13396 ms) tcp{client}: 0xf5619c8
2021-04-17 20:59:28.453   openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=687028312&_=1618687270166 HTTP/1.1 tcp{client}: 0xf5619c8
2021-04-17 20:59:28.931   openLuup.server:: request completed (766007 bytes, 48 chunks, 476 ms) tcp{client}: 0xf5619c8
2021-04-17 20:59:32.943   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 20:59:32.994   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=687035197&Timeout=60&MinimumDelay=1500&_=1618687270167 HTTP/1.1 tcp{client}: 0xf5619c8
2021-04-17 20:59:33.059   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 20:59:33.538   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 20:59:33.630   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 20:59:34.639   luup.variable_set:: 30004.shellyix3-rear.online was: EMPTY now: true #hooks:0
2021-04-17 20:59:34.763   openLuup.server:: request completed (3732 bytes, 1 chunks, 1767 ms) tcp{client}: 0xf5619c8
2021-04-17 20:59:34.813   openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=687028316&_=

Devices still work after mosquitto restart

Will now reload luup and double check If this does infact cause devices to fail.