search

Hypfer / Valetudo

Cloud replacement for vacuum robots enabling local-only operation
https://valetudo.cloud
Apache License 2.0
6.33k stars 387 forks source link

Viomi V8 map not saved #1170

Closed benoegen closed 1 year ago

benoegen commented 2 years ago

Describe the bug

Whenever the checkbox for persistant data is checked and save is pressed, the next time the page is opened it is unchecked again. The robot also creates a new map whenever it starts cleaning.

To Reproduce

Steps to reproduce the behavior:

  1. Go to 'persistant data'
  2. Check 'enabled' & 'save'
  3. Leave page and go back to 'persistant data'
  4. See error

Vacuum Model

Viomi V8, April 2021

Valetudo Version

2021.10.0 and older

Expected behavior

Checkbox remains checked and map data is saved.

Additional context

[1970-01-04T03:41:20.889Z] [DEBUG] Map upload started with: {
  query: {
    ts: '271919636806325',
    suffix: 'urls',
    Expires: '272818',
    index: '0',
    method: '_sync.gen_tmp_presigned_url'
  },
  params: { filename: undefined }
}
[1970-01-04T03:41:20.950Z] [DEBUG] <<< cloud: {"result":["ok"],"id":15746}
[1970-01-04T03:41:20.951Z] [DEBUG] << cloud: ignoring response for non-pending request {"result":["ok"],"id":15746}
[1970-01-04T03:41:38.217Z] [DEBUG] <<< cloud* {"stamp":272497}
[1970-01-04T03:41:38.218Z] [DEBUG] >>> cloud* {"stamp":272497}
[1970-01-04T03:41:58.217Z] [DEBUG] <<< cloud* {"stamp":272517}
[1970-01-04T03:41:58.218Z] [DEBUG] >>> cloud* {"stamp":272517}
[1970-01-04T03:42:04.051Z] [DEBUG] >>> cloud: {"method":"set_remember","params":[1],"id":15750}
[1970-01-04T03:42:04.098Z] [DEBUG] <<< cloud: {"result":["ok"],"id":15750}
reallyuniquename commented 2 years ago

I think I'm having the same issue on v7. Log is flooded with this.

[2021-10-19T13:10:04.770Z] [DEBUG] >>> cloud* {"stamp":1634649005}
[2021-10-19T13:10:12.221Z] [DEBUG] Map upload started with: {
  query: {
    ts: '51897555027',
    suffix: 'urls',
    Expires: '1634649608',
    index: '0',
    method: '_sync.gen_tmp_presigned_url'
  },
  params: { filename: undefined }
}
[2021-10-19T13:10:12.327Z] [DEBUG] <<< cloud: {"result":["ok"],"id":12}
[2021-10-19T13:10:12.328Z] [DEBUG] << cloud: ignoring response for non-pending request {"result":["ok"],"id":12}
[2021-10-19T13:10:24.768Z] [DEBUG] <<< cloud* {"stamp":1634649025}
[2021-10-19T13:10:24.769Z] [DEBUG] >>> cloud* {"stamp":1634649025}

And this is when I try to enable persistent data although it still stays off in UI.

[2021-10-19T13:28:10.769Z] [DEBUG] >>> cloud: {"method":"set_remember","params":[1],"id":36}
[2021-10-19T13:28:10.808Z] [DEBUG] <<< cloud: {"result":["ok"],"id":36}
drticcz commented 2 years ago

I am having same issue, although slightly different symptoms - I don't see anything about the map upload attempt in the logs at all (level TRACE)

/etc/miio/device.conf:
...
vendor=viomi
mac=50:EC:50:EF:2C:D2
model=viomi.vacuum.v7
/mnt/UDISK/valetudo_config.json:

{
  "embedded": true,
  "robot": {
    "implementation": "auto",
    "implementationSpecificConfig": {
      "ip": "127.0.0.1"
    }
  },
  "webserver": {
    "port": 80,
    "basicAuth": {
      "enabled": false,
      "username": "valetudo",
      "password": "valetudo"
    },
    "blockExternalAccess": true
  },
  "zonePresets": {},
  "goToLocationPresets": {},
  "mqtt": {
    "enabled": false,
    "connection": {
      "host": "foobar.example",
      "port": 1883,
      "tls": {
        "enabled": false,
        "ca": ""
      },
      "authentication": {
       "credentials": {
          "enabled": false,
          "username": "",
          "password": ""
        },
        "clientCertificate": {
          "enabled": false,
          "certificate": "",
          "key": ""
        }
      }
    },
    "identity": {
      "friendlyName": "",
      "identifier": ""
    },
    "interfaces": {
      "homie": {
        "enabled": true,
        "addICBINVMapProperty": false,
        "cleanAttributesOnShutdown": false
      },
      "homeassistant": {
        "enabled": true,
        "cleanAutoconfOnShutdown": false
      }
    },
    "customizations": {
     "topicPrefix": "",
      "provideMapData": true
    }
  },
  "ntpClient": {
    "enabled": true,
    "server": "pool.ntp.org",
    "port": 123,
    "interval": 28800000,
    "timeout": 10000
  },
  "timers": {},
  "logLevel": "info",
  "debug": {
    "systemStatInterval": false,
    "debugHassAnchors": false,
    "storeRawUploadedMaps": false
  },
  "networkAdvertisement": {
    "enabled": true
  },
  "updater": {
    "enabled": true,
    "updateProvider": {
      "type": "github",
      "implementationSpecificConfig": {}
    }
  }
}

/mnt/UDISK/config/sysConfig.ini:

[Sys_Config]
server_cmd_address=das.3irobotics.net
server_map_address=das.3irobtoics.net
server_log_address=log.3irobotics.net
server_ota_address=ota.3irobotics.net
server_ssl_cmd_port=5010
server_ssl_map_port=5030
server_ssl_enable=0
server_cmd_port=4010
server_map_port=4030
server_sync_time_port=4050
server_log_port=21
server_ota_check_port=5000
server_ota_download_port=2300
wlan_port=8111
wlan_broad_port=8888
deviceFirmsID=1021
deviceType=4
languageType=1
hardwareRtc=0
timezoneSec=28800

I have tried to edit following lines here but no change:

server_cmd_port=8053 (to point to dummycloud)

server_map_port=8079 (to point to map upload server)

/etc/hosts:

127.0.0.1 localhost

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 ot.io.mi.com ott.io.mi.com
127.0.0.1 de.ot.io.mi.com de.ott.io.mi.com
127.0.0.1 ea.ot.io.mi.com ea.ott.io.mi.com
127.0.0.1 in.ot.io.mi.com in.ott.io.mi.com
127.0.0.1 pv.ot.io.mi.com pv.ott.io.mi.com
127.0.0.1 ru.ot.io.mi.com ru.ott.io.mi.com
127.0.0.1 sg.ot.io.mi.com sg.ott.io.mi.com
127.0.0.1 st.ot.io.mi.com st.ott.io.mi.com
127.0.0.1 tw.ot.io.mi.com tw.ott.io.mi.com
127.0.0.1 us.ot.io.mi.com us.ott.io.mi.com
127.0.0.1 das.3irobotics.net
127.0.0.1 das.3irobtoics.net
127.0.0.1 log.3irobotics.net
127.0.0.1 ota.3irobotics.net
/var/valetudo.log:
Note - there is no "cloud connected" message

[1970-01-01T00:00:33.847Z] [INFO] Set Logfile to /tmp/valetudo.log
[1970-01-01T00:00:33.862Z] [INFO] Autodetected ViomiV7ValetudoRobot
[1970-01-01T00:00:33.978Z] [INFO] Starting Valetudo 2022.02.0
[1970-01-01T00:00:33.981Z] [INFO] Commit ID: dde8f2ef28d8c7cd6b7456f6628595f9613dbf74
[1970-01-01T00:00:33.982Z] [INFO] Configuration file: /mnt/UDISK/valetudo_config.json
[1970-01-01T00:00:33.984Z] [INFO] Logfile: /tmp/valetudo.log
[1970-01-01T00:00:33.985Z] [INFO] Robot: Viomi V7 (ViomiV7ValetudoRobot)
[1970-01-01T00:00:33.985Z] [INFO] JS Runtime Version: v16.10.0
[1970-01-01T00:00:33.986Z] [INFO] Arch: arm
[1970-01-01T00:00:33.988Z] [INFO] Max Heap Size: 38 MiB
[1970-01-01T00:00:33.989Z] [INFO] Node Flags: --expose-gc --max-heap-size=38
[1970-01-01T00:00:34.007Z] [INFO] Autogenerated System ID: WindingExcitedOpossum
[1970-01-01T00:00:34.011Z] [INFO] DeviceId 277973627
[1970-01-01T00:00:34.012Z] [INFO] IP 127.0.0.1
[1970-01-01T00:00:34.013Z] [INFO] CloudSecret #####censored########
[1970-01-01T00:00:34.014Z] [INFO] LocalSecret #####censored########
[1970-01-01T00:00:48.925Z] [INFO] Valetudo can be reached via: valetudo-windingexcitedopossum.local
[1970-01-01T00:00:48.961Z] [INFO] Setting /proc/self/oom_score_adj to 666. Previous value: -1000
[1970-01-01T00:00:48.975Z] [INFO] Dummycloud is spoofing 127.0.0.1:8053 on 127.0.0.1:8053
[1970-01-01T00:00:48.978Z] [INFO] Webserver running on port 80
[1970-01-01T00:00:48.988Z] [INFO] SSDP/UPnP advertisement started
[1970-01-01T00:00:49.002Z] [INFO] Map Upload Server running on port 8079
[1970-01-01T00:00:49.023Z] [INFO] Bonjour service "Valetudo V7 Web" with type "http" started
[1970-01-01T00:00:49.024Z] [INFO] Bonjour service "Valetudo V7" with type "valetudo" started
[1970-01-01T00:00:49.063Z] [INFO] Got token from handshake: 307866446e57306b445556474c4e3962
[2022-02-02T06:02:13.003Z] [INFO] Successfully set the robot time via NTP to 2022-02-02T06:02:13.897Z
[2022-02-02T06:08:58.126Z] [INFO] Got an expired token. Changing to new
[2022-02-02T06:08:58.133Z] [INFO] Got token from handshake: 307866446e57306b445556474c4e3962
[2022-02-02T06:10:59.344Z] [INFO] Got an expired token. Changing to new
johnappletree commented 2 years ago

I had a similar issue on my Viomi V7. For me the map data was not received by Valetudo. I was therefore stuck at the no map data image. During debugging it looked like spoofing the miio_client did not do what it was supposed to do. With the help from @Hypfer , it turned out to be the WiFi settings! After entering my WiFi credentials again in the Valetudo WiFi sections the map started working again.

Could you try that? maybe this also works for you?

drticcz commented 2 years ago

Re adjusting the wifi settings did not help.. I am trying to decipher how this whole ecosystem should work in order to debug where it is failing but so far I am confused. This is afaik not described in any existing documentation. Maybe if you help me to understand the basics, I will be able to compose some troubleshooting wiki.

The maps suddenly appeared but I think it is still partially broken as the communication is timing out - most likely the time setting is the issue here, as Valetudo keeps complaining on the time sync, although I applied the workaround from https://github.com/Hypfer/Valetudo/issues/1156

2022-02-05T04:57:27.807Z] [TRACE] Raw robot angle -0.22859540581703186 -13.097551969396234 calculated 193.09755196939622
[2022-02-05T04:57:27.895Z] [DEBUG] <<< cloud: {"id":79,"error":{"code":-9999,"message":"user ack timeout"}}
[2022-02-05T04:57:27.896Z] [TRACE] Miio error response { id: 79, error: { code: -9999, message: 'user ack timeout' } }
[2022-02-05T04:57:27.898Z] [WARN] Error while adjusting timezone to UTC
[2022-02-05T04:57:27.900Z] [DEBUG] <<< cloud: {"id":78,"error":{"code":-9999,"message":"user ack timeout"}}
[2022-02-05T04:57:27.901Z] [TRACE] Miio error response { id: 78, error: { code: -9999, message: 'user ack timeout' } }
[2022-02-05T04:57:27.903Z] [WARN] Error while adjusting timezone to UTC

/usr/sbin/date

echo "UTC" > /etc/TZ
/bin/date -u -s "$2"
sleep 2
/bin/date -u -s "$2"
sleep 2
/bin/date -u -s "$2"
sleep 2
/bin/date -u -s "$2"

the real system date is UTC

root@TinaLinux:~# /bin/date
Sat Feb  5 05:17:44 UTC 2022

However /etc/config/system is still different, originally there was ICT-8 / Beijing

config system
        option hostname TinaLinux
        option timezone Asia/Bangkok
        option timezone ICT-7

config timeserver ntp
        list server 192.168.1.2
        list server ntp5.aliyun.com
        list server 0.openwrt.pool.ntp.org
        list server 0.cn.pool.ntp.org
        option enable 1
        option enable_server 0

Am I missing another setting?

johnappletree commented 2 years ago

This is my NTP story for my Viomi v7: I noticed that the robot has two NTP clients. I found this out because my robot is connected to an internet disabled WiFi vlan. First I set the NTP server in the valetudo config file to a lan NTP Server. Afterwards, I noticed unresolved DNS requests to the http://0.openwrt.pool.ntp.org/ wich I had chanced in the config file. Changing the NTP server in the web interface resolved the DNS http://0.openwrt.pool.ntp.org/ requests. I think valetudo has a build in NTP client which is disconnected from the systems NTP client.

How did you configure NTP in the config and webinterface? Is the data consistent?

drticcz commented 2 years ago

Seems like I will have to try dig deeper in the Valetudo code to figure out how exactly is it trying to set the TZ. I tried to disable the internal NTP in Valetudo and it looks like the system NTP client is not running at all although from the config ut seems like it does, as the time stays on 1970...

lukyjay commented 1 year ago

Seems like I will have to try dig deeper in the Valetudo code to figure out how exactly is it trying to set the TZ. I tried to disable the internal NTP in Valetudo and it looks like the system NTP client is not running at all although from the config ut seems like it does, as the time stays on 1970...

See the FAQ on setting timezones: https://valetudo.cloud/pages/faq.html

Where do I configure the Timezone? The timezone on the device cannot be changed. It is always UTC.

Every feature in Valetudo that uses time will automatically use the local time reported by your browser. This means you do not have to worry about it. It is handled by the application itself.

The only instance where the time is relevant, is when looking at the Valetudo logs, which are in UTC (as mentioned above).

Hypfer commented 1 year ago

Please check if this is still an issue with the latest version of Valetudo and a fresh firmware built with the dustbuilder.

If so, please open a new ticket