Automated Somfy blinds with D1 Mini & MQTT - Templated sensors help syntax needed

Configuration
,
1

Hi Folks

I have munged some great work by others to automate a set of Somfy blinds I have, using MQTT, a D1 Mini, 433.42 Mhz transmitter and some bad yaml. I can control the blinds successfully via covers configured like this - with similar config for all 4 blinds:

- platform: mqtt
  name: "Somfy Blind 1"
  device_class: "blind"
  command_topic: "homeassistant/livingRoom/blind1"
  availability_topic: "homeassistant/virtual-somfy-remote/status"
  payload_open: "u"
  payload_close: "d"
  payload_stop: "s"
  retain: false

What I want to do is to “save” the value of a rolling code that gets incremented each time my “virtual” remote transmits. I pass this information back via an MQTT “ack”, which contains the following JSON formatted data:

{"Name":"blind2","RemoteID": "0x121312","Code": 107,"Cmd": "u"}

My first attempt is using a number of sensors. My first sensor subscribes to the common MQTT “ack” and populates attributes in the sensor state:

- platform: mqtt
  name: Somfy Blind Ack
  state_topic: "homeassistant/virtual-somfy-remote/ack"
  json_attributes_topic: "homeassistant/virtual-somfy-remote/ack"

I can see this working, with the sensor.somfy_blind_ack getting set correctly:

Name: blind2
RemoteID: 0x121312
Code: 107
Cmd: u
friendly_name: Somfy Blind Ack

I then have template sensors for each of the different blinds, so I can extract and store the rolling code for each blind:

- platform: template
  sensors:
    somfy_blind1_rc:
      friendly_name: "Somfy Blind1 Last Rolling Code"
      value_template: >-
          {% if is_state_attr('sensor.somfy_blind_ack', 'Name','blind1') %}
            {{state_attr('sensor.somfy_blind_ack', 'Code') }}
          {% endif %}
    somfy_blind2_rc:
      friendly_name: "Somfy Blind2 Last Rolling Code"
      value_template: >-
          {% if is_state_attr('sensor.somfy_blind_ack', 'Name','blind2') %}
            {{state_attr('sensor.somfy_blind_ack', 'Code') }}
          {% endif %}

And these work to a certain extent as well - but what happens (and it makes sense) is that when the “Blind2” ack comes back, all the other sensors get reset, as their value_template obviously gets wiped.

Basically - I either need a way of keeping the existing sensor values in all but the one getting updated, or another way of attacking this. I don’t really need these to be separate sensors - I just want to save a log of the rolling codes (ultimately so when my D1 mini ultimately craps itself - I can restore the codes).

This is my first attempt at templates (apart from copying the good work of those before me) - but no amount of searching has led me to a similar setup.

Any pointers appreciated.

Cheers,
Chris

2

Your question has been instrumental in helping me with the same problem ,(multiple sensors in the same mqtt topic). You have probably already found a solution, but this is what I did, just add an {% else %} and populate it with itself.

- platform: template
  sensors:
    somfy_blind1_rc:
      friendly_name: "Somfy Blind1 Last Rolling Code"
      value_template: >-
          {% if is_state_attr('sensor.somfy_blind_ack', 'Name','blind1') %}
            {{state_attr('sensor.somfy_blind_ack', 'Code') }}
          {% else %}
            {{ states('sensor.somfy_blind1_rc') }}
          {% endif %}
3

Hey @allew864 - I missed this post when you made it. Long story short - no I haven’t progressed with this, so will give your suggestion a shot!

Thanks!

4

That did it! Awesome.

5

The challenge of handling a single MQTT topic containing payloads from multiple devices is explored in this thread:

It offers two strategies for handling the situation. The first is the one you’ve already employed. The sensor’s value_template inspects the received payload and either extracts the value or, if the payload was not intended for it, simply reports its existing state value.

The second strategy is more efficient when there are many sensors involved (> 3). It uses a simple automation to demultiplex the single MQTT topic into multiple topics, namely one unique topic per device. This greatly simplifies the configuration of each individual sensor.

1 Like
6

Oh wow - that’s the thread I needed :slight_smile: !
I’ll also now replace some of my Sonoff RF Bridge PIR sensor old-style “off” automations to using that “off_delay” setting right now as a first step, and then digest Strategy 2. Great stuff.

1 Like
7
  • Imagine a distribution center with a single conveyor belt.
  • Packages destined for different cities roll along the conveyor belt.
  • At the end of the conveyor, a person examines the address on each package and, based on the city, loads it onto a truck heading to that city.

Strategy 2’s automation, is like the person at the end of the conveyor. It examines the payload, determines which device it belongs to, then publishes it to that device’s topic.

In this diagram, an automation called DEMUX is subscribed to home/sensors. This single topic contains payloads from many sensor devices. DEMUX redirects each received payload to a topic that is unique to each sensor device.

home/sensors ==> DEMUX ----> home/sensor1
                       |
                       |---> home/sensor2
                       |
                       |---> home/sensor3
                       |
                       |---> home/sensor4
                       |
                       |---> home/sensor5

Then in Home Assistant, you define 5 sensors where each one is subscribed to its own unique topic:

home/sensor1 ==> sensor.something1
home/sensor2 ==> sensor.something2
home/sensor3 ==> sensor.something3
home/sensor4 ==> sensor.something4
home/sensor5 ==> sensor.something5

The conveyor belt analogy can also be used to explain Strategy #1 (although the analogy is bit strained). In that scenario, all the truck drivers are standing at the end of the conveyor belt and inspecting every package. They take only what’s destined for their city.

1 Like