After Reboot of the installed Linux, ValetudoRE starts Zoned Cleanup automatical?

[nicedevil007]

Describe the bug
Since 2 days the robot seems to make a reboot of the linux every night at 3:25 AM (yes in the middle of the night.....) and then it starts to wakeup everybody in my flat. I can 100% reproduce the behaviour with a manual reboot of the system.

How to Reproduce
Steps to reproduce the behavior:

1. Reboot the installed Linux with shell commannd "reboot"
2. After the reboot is done the robot starts a zoned cleanup

Expected behavior
The robot waits until it gets the specific command to do a cleanup.

Screenshots

Vacuum Model:
Gen 2 S5

Valetudo Version: latest of 2021/06/10

User-Agent

Additional context

[rand256]

robot seems to make a reboot of the linux every night at 3:25 AM (yes in the middle of the night.....)

Yes, that's exactly what manufacturer wanted the device to do - it's not related to valetudo in any way.

I can 100% reproduce the behaviour with a manual reboot of the system.

Just tried to enable some zoned cleaning in UI to run every day, then logged on to ssh and issued reboot command. Device has silently reboot and... did nothing as expected.

Can you copy some logs from Settings -> System Log?

[nicedevil007]

If it is a command done by Node-RED via MQTT it would get a pushmessage to my phone, but there isn't any.

2021-06-10T16:51:27.784Z Timesync packet received
2021-06-10T16:21:27.784Z Timesync packet received
2021-06-10T15:51:27.785Z Timesync packet received
2021-06-10T15:21:27.785Z Timesync packet received
2021-06-10T14:51:27.519Z Timesync packet received
2021-06-10T14:51:27.516Z Robot connected
2021-06-10T14:51:25.102Z MQTT Error :  : Received unknown command
2021-06-10T14:51:21.557Z MQTT Error :  : Received unknown command
2021-06-10T14:51:21.327Z Connected successfully to mqtt server
2021-06-10T14:51:20.671Z Probed last id = 1001 using get_status (3 retries)
2021-06-10T14:51:19.643Z Webserver is running on port 80 (http)
2021-06-10T14:51:19.638Z Dummycloud is spoofing 203.0.113.1:8053 on 127.0.0.1:8053
2021-06-10T14:51:19.546Z No ssl key found. Expected path: /mnt/data/valetudo/key.pem
2021-06-10T14:51:19.544Z No ssl cert found. Expected path: /mnt/data/valetudo/cert.pem
2021-06-10T14:51:19.409Z timesync: giving up
2021-06-10T14:51:08.464Z timesync: retry
2021-06-10T14:50:57.521Z timesync: retry
2021-06-10T14:50:46.571Z timesync: retry
2021-06-10T14:50:36.461Z Loading configuration file: /mnt/data/valetudo/config.json

[rand256]

So it's not related to scheduled cleanings. (Why did I think it should?..)

If mqtt is involved here as it suddenly appears, then probably what you see can be explained this way: you post a mqtt command to start cleaning, it is being put to the broker as something in mqtt terms called retained message, the device sees the message, starts the cleaning and everything is okay. But. Then the device is restarted by low-level firmware logic. It restarts and reconnects to mqtt - and what does it see? It sees the command to start cleaning again at the broker. Because it was marked to be "retainable" or something (?). So, device looks at this message and starts cleaning. Immediately. Looks logical to me.

tl;dr
Send the command as normal, one-time, not retained message.
I guess nothing could be done for this issue from valetudo's side (probably).

[nicedevil007]

That is what I was trying to tell you: MQTT is used since many years now and it wasn't set (and isn't set) to retained flag.

The command that is sent to the MQTT Broker is the following:

    return {payload: {
            command: 'zoned_cleanup',
            zone_ids: [
                'Küche',
                'Flur',
                'Büro',
                'Schlafzimmer',
                'Wohnzimmer']
            }
    }

Nothing special in my opinion. Nothing more is configured :/

[rand256]

Well, which valetudo version did work properly for you? You could temporarily replace the current binary with the old one to see whether mqtt would work correctly with the old version.

Though I guess it won't help, cause I've already posted the only explanation I could imagine for why valetudo would run cleaning again just upon re-connecting to mqtt. Btw probably you can just turn mqtt off in UI and then on again - and this will also lead to immediately starting cleaning if your command message is somehow stuck on the broker and being re-sent to the device every time it connects.

But I could be wrong - my experience with the whole mqtt thing isn't that deep.

[nicedevil007]

I will try to enter wrong MQTT credentials so it won't connect on reboot and do a reboot afterwards. That should tell me if MQTT is the reason or not. Will report back, thank you so far for your help

[nicedevil007]

Nothing happens after reboot when MQTT is disabled, so you are right :(
Sry for the unhappy smiley but that is soooooo strange... nothing is configured for retained flag here but it is still happening waaaaaaaaaah. Ok so we can close this for now!

Again, Thank you!

[nicedevil007]

I found the issue! That was a setting of the MQTT broker itself inside ioBroker.

Eigene States beim Verbinden publizieren

In english:

Publish own states on connect

Nothing to do with retained settings for this topic but is close to be the same feature.