Untimely opening / closing of roller shutter !?

[Christian1]

Hello,

I contact you because after 3 days of installation/configuration of Eltako FSB61NP actuators by Enocean PI, and MQTT publication to Home Assistant, my roller shutters opened untimely (@2.57am) and closed untimely (@14:40 pm) !? 
To make a diagnostic :
- I have checked the voice control IFTTT log of these roller shutter : I don't see any event at these hours
- I have checker Home Assistant log : I don't see any event at the hours
- I have seen these messages in my actual FHEM log (I am going to add again the verbose into my MQTT2_CLIENT and MQTT_GENERIQUE_BRIDGE) where we see a disconnection/reconnection which seems to cause the opening or closing.

Please can you help me to know what is going wrong ? how to secure these untimely MQTT disconnection/publication  ?
Thanks a lot for your help !

Code Auswählen Erweitern

2020.06.10 14:40:01 1: 192.168.1.32:1883 disconnected, waiting to reappear (examplemqtt)
2020.06.10 14:40:06 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.10 14:40:08 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch4_FSB61 stop
2020.06.10 14:40:36 2: examplemqtt: No PINGRESP for last PINGREQ (at 2020-06-10 14:39:45), disconnecting
2020.06.10 14:40:36 1: 192.168.1.32:1883 disconnected, waiting to reappear (examplemqtt)
2020.06.10 14:40:46 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.10 14:40:46 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.10 14:40:46 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.10 14:40:46 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.10 14:40:46 3: EnOcean set EnO_switch4_FSB61 stop
2020.06.11 02:56:54 1: 192.168.1.32:1883 disconnected, waiting to reappear (examplemqtt)
2020.06.11 02:56:59 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.11 02:57:01 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.11 02:57:01 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.11 02:57:01 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.11 02:57:01 3: EnOcean set EnO_switch4_FSB61 stop
2020.06.11 02:57:29 2: examplemqtt: No PINGRESP for last PINGREQ (at 2020-06-11 02:56:38), disconnecting
2020.06.11 02:57:29 1: 192.168.1.32:1883 disconnected, waiting to reappear (examplemqtt)
2020.06.11 02:57:39 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.11 02:57:39 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.11 02:57:39 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.11 02:57:39 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.11 02:57:39 3: EnOcean set EnO_switch4_FSB61 stop
2020.06.11 06:34:04 2: AttrTemplates: got 127 entries

Maybe these status maybe can also help to the diagnostic :

Code Auswählen Erweitern

manufProfile
EnO_switch1_FSB61   open_ack       opens    stop   closes
EnO_switch2_FSB61   up                 opens    stop   closes
EnO_switch3_FSB61   open_ack       opens    stop   closes
EnO_switch4_FSB61   not_reached   opens    stop   closes

[KölnSolar]

where we see a disconnection/reconnection which seems to cause the opening or closing.

I agree. Seems to be a kind of initalization after reconnecting(network).

2020.06.10 14:40:06 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.10 14:40:08 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.10 14:40:08 3: EnOcean set EnO_switch4_FSB61 stop

how to secure these untimely MQTT disconnection/publication  ?

In general I'd say it is not possible because network problems may occur every time for different reasons.
Since I don't have such a configuration

Eltako FSB61NP actuators by Enocean PI, and MQTT publication to Home Assistant

I can't give you an answer where to find such a kind of initialization in your environment.

Maybe my answer helps a little bit to find the cause yourself.

[Beta-User]

IMO set commands may be the deeper cause for this kind oft effect. Are they sent with retain flag?
In cause if: change to simple send.

[Christian1]

Hello KölnSolar and Beta-User,

I thank you for your answers : my voice IFTTT commands to HA seems to send commands to FHEM with "retain= True". If I understand : 1) when reconnexion happens this "retains" proposes to send again the action again to open or close the shutters 2) so you advise me to put my HA MQTT publications "retain" to "False", isn't it ?

See bellow one example of HA command for controling EnO_switch2_FSB61 (with retain= True)

Code Auswählen Erweitern

- platform: mqtt
    name: "MQTT EnO_switch2_FSB61"
    command_topic: "enocean/EnO_switch2_FSB61/set"
    state_topic: "enocean/EnO_switch2_FSB61/state"
    qos: 0
    retain: true
    payload_open: "closes"
    payload_close: "opens"
    payload_stop: "stop"
    state_opening: "opening"
    state_closed: "closed"
    state_closing: "closing"

See bellow the result on FHEM log :

Code Auswählen Erweitern

2020.06.08 09:26:42 5: examplemqtt: received PUBLISH (0)(29)enocean/EnO_switch1_FSB61/setcloses
2020.06.08 09:26:42 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch1_FSB61/set\000closes
2020.06.08 09:26:42 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch1_FSB61/set => closes
2020.06.08 09:26:42 3: EnOcean set EnO_switch1_FSB61 closed
2020.06.08 09:26:42 5: examplemqtt: received PUBLISH (0)(29)enocean/EnO_switch3_FSB61/setcloses
2020.06.08 09:26:42 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch3_FSB61/set\000closes
2020.06.08 09:26:42 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch3_FSB61/set => closes
2020.06.08 09:26:42 3: EnOcean set EnO_switch3_FSB61 closed
2020.06.08 09:26:42 5: examplemqtt: received PUBLISH (0)(29)enocean/EnO_switch2_FSB61/setcloses
2020.06.08 09:26:42 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch2_FSB61/set\000closes
2020.06.08 09:26:42 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch2_FSB61/set => closes
2020.06.08 09:26:42 3: EnOcean set EnO_switch2_FSB61 closed
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: enocean/EnO_switch1_FSB61/state => down (qos: 0, retain: 0)
2020.06.08 09:26:43 5: examplemqtt: sending PUBLISH 0%(0)(31)enocean/EnO_switch1_FSB61/statedown
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: enocean/EnO_switch3_FSB61/state => down (qos: 0, retain: 0)
2020.06.08 09:26:43 5: examplemqtt: sending PUBLISH 0%(0)(31)enocean/EnO_switch3_FSB61/statedown
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: enocean/EnO_switch2_FSB61/state => down (qos: 0, retain: 0)
2020.06.08 09:26:43 5: examplemqtt: sending PUBLISH 0%(0)(31)enocean/EnO_switch2_FSB61/statedown
2020.06.08 09:26:43 5: examplemqtt: received PUBLISH (0)(31)enocean/EnO_switch1_FSB61/statedown
2020.06.08 09:26:43 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch1_FSB61/state\000down
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch1_FSB61/state => down
2020.06.08 09:26:43 5: examplemqtt: received PUBLISH (0)(31)enocean/EnO_switch3_FSB61/statedown
2020.06.08 09:26:43 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch3_FSB61/state\000down
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch3_FSB61/state => down
2020.06.08 09:26:43 5: examplemqtt: received PUBLISH (0)(31)enocean/EnO_switch2_FSB61/statedown
2020.06.08 09:26:43 5: examplemqtt: dispatch autocreate=no\000examplemqtt\000enocean/EnO_switch2_FSB61/state\000down
2020.06.08 09:26:43 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'examplemqtt'): Msg: enocean/EnO_switch2_FSB61/state => down

[Beta-User]

Recommending sth. wrt. your question and setup isn't easy. Your observation is a result of (most likely) three prerequisites:

- command sent as "retain" to Broker/FHEM;
- followed by a different command from outside your MQTT setup (FHEM or e.g. buttons attached to the hardware?);
- disconnect on the Server/Client-side.

If you are steering your shutters only by MQTT commands, any disconnect will lead to no different move => no problem;
if you would have sent without retain => no renewed command from MQTT => no problem (a);
- no disconnect => no renewed command from MQTT => no problem (b).

As (a) might lead to lost messages in case your network environment is not stable, this might not be the best solution, but an acceptable trade-off... Perhaps using a QoS-flag without retain would be the preferrable way? (didn't have a deeper look at that)
Best would be to solve (b), but this e.g. might also be related to a FHEM or mosquitto-restart? If that happens as intented, you don't have big options to avoid that kind of effects...

You might even consider revoking the retain flag, after the command has been executed from within FHEM or FHEM detects manual steering? The latter might be a little tricky.
Or to avoid any steering from non-MQTT-side... It's up to you, hope, this helps to get a better understanding what to look at first.

[Christian1]

Hello Beta-User,

Thank you for your explanations
- yes I think it happened when I used different ways to control the roller shutters : with remote control, with FHEM, with MQTT
- There is no date on this Home Assistant / Mosquitto log, so I don't where these kind of errors happens

Code Auswählen Erweitern

1592070350: Socket error on client examplemqtt, disconnecting.
1592070350: New connection from 172.30.32.1 on port 1883.
1592070350: New client connected from 172.30.32.1 as examplemqtt (p1, c1, k30, u'Christian1').
On FHEM the kind of errors:

Code Auswählen Erweitern

2020.06.13 19:46:03 1: 192.168.1.32:1883 disconnected, waiting to reappear (examplemqtt)
2020.06.13 19:46:03 1: 192.168.1.32:1883 reappeared (examplemqtt)
2020.06.13 19:46:04 3: EnOcean set EnO_switch1_FSB61 open
2020.06.13 19:46:04 3: EnOcean set EnO_switch2_FSB61 open
2020.06.13 19:46:04 3: EnOcean set EnO_switch3_FSB61 open
2020.06.13 19:50:18 1: /dev/ttyS0 disconnected, waiting to reappear (TCM310_0)
2020.06.13 19:50:18 3: Setting TCM310_0 serial parameters to 57600,8,N,1
2020.06.13 19:50:18 1: /dev/ttyS0 reappeared (TCM310_0)
I will watch if it happens again

[xenos1984]

- There is no date on this Home Assistant / Mosquitto log, so I don't where these kind of errors happens

Code Auswählen Erweitern

1592070350: Socket error on client examplemqtt, disconnecting.
1592070350: New connection from 172.30.32.1 on port 1883.
1592070350: New client connected from 172.30.32.1 as examplemqtt (p1, c1, k30, u'Christian1').

Are you sure that the first number is not a Unix timestamp? I don't know your time zone used to display local time in the FHEM, but the day fits:

Code Auswählen Erweitern

date -d '@1592070350' -u
Sa 13. Jun 17:45:50 UTC 2020
So if your time zone happens to be UTC+2 (as it is in central Europe during summer), that would be just 13 seconds before the FHEM log's first entry.

[Christian1]

Hello Xenos1984, yes, I am French with UTC+2

[Christian1]

Hello, I have still the problem. Now, the problem happens like that : it moves down 3 of my 7 roller shutters when I restart my Raspberry PI, the other 4 roller shutter stay opened. So that is why I exceptionnaly share you this picture showing : on left side, one of the 3 roller shutters going wrong, and on the right side, one of the roller shutters which works well.
You will see that the internals are differents. Do you think that, by typing some commands on the 3 roller shutters for suppressing the TCM310-... things, it can help me to solve my problem ? 

[Beta-User]

From my side, I have no clue what to take as conclusion from the screenshot. Could be a problem from within enocean side when all commands shall be executed in parallel?

But the question still should be: is ist ok when there are commands executed, when your Pi restarts? Imo this is not a desired behaviour at all...

For getting more info, what's getting on on the MQTT side, you have to subscribe to the same topics on your mosquitto server with an external tool.

(Btw. is there a specific cause for the "/" in general settings? Ist the attribute as such necessary or used?)