Nicely done! Thank you.
I’ve implemented the changes in my setup last evening and here is some feedback:
I have 3 Gateways:
- first one has 5 TRVs and 2 H&T sensors
- second one has 3 TRVs and 3 H&T sensors
- third one has one TRV
The automation that asks for the statuses, cycles through all of the devices and sends the request for each device. I can share the automation configuration, for who wants to use it.
I’ve noticed that only one TRV per gateway had the new topic with the response.
After a bit of empiric testing, I’ve figured out, that it might had to do with sending too many requests at once to one Blu GW. So I modified the automation to include some delays between the requests.
On a separate note, yesterday evening I managed to make on Gw to crash compleetely, by just enabling the debugging over MQTT. It crashed completely, the web server that renders the local page was not starting anymore and the BLU Gw was rebooting every minute or so. I ended up doing a factory reset, which even that was no easy task, as it was crashing.
My point with this, it might be that the BLU Gw are not super-reliable, to stress them.
I’m curious what is your experience so far with this new MQTT configuration and the automation, in regards to the BLU Gw.
alias: Shelly BLU TRV get status
description: Get Shelly BLU TRV status every 5 minutes
triggers:
- trigger: time_pattern
minutes: /5
conditions: []
actions:
- variables:
devices:
- shellyblugwg3-aabbccddeeff/status/blutrv:200
- shellyblugwg3-ttuuvvxxyyzz/status/blutrv:200
- shellyblugwg3-aabbccddeeff/status/blutrv:201
- shellyblugwg3-ttuuvvxxyyzz/status/blutrv:201
- repeat:
for_each: "{{ devices }}"
sequence:
- action: mqtt.publish
data:
topic: "{{ repeat.item.split('/')[0] ~ '/rpc' }}"
payload: |-
{
"id": 0,
"src": "{{ repeat.item }}",
"method": "BluTRV.Call",
"params": {
"id": {{ repeat.item.split(':')[1] }}
"method": "TRV.GetStatus",
"params": {
"id": 0
}
}
} | tojson
- delay: "00:00:10"
mode: single
