Xiamoni Vacuum / Roborock: MQTT-Ansteuerung mit Valetudo / attrTemplate

Begonnen von krikan, 27 Oktober 2019, 09:50:12

Vorheriges Thema - Nächstes Thema

Beta-User

Ah, ok. Aber dann brauchen wir bei Nutzung dieser Extension den map_data-Zweig eigentlich in dem MQTT2_DEVICE gar nicht, oder?

Bzw. die kann dann so aussehen:
readingList valetudo/rockrobo/map_data:.* {}
(Das MQTT2_DEVICE leitet nichts weiter, das macht der MQTT-Server).

(Wenn die extern erzeugte Karte irgendwie "besser" ist als die interne, wäre es natürlich toll, wenn "unser" code auch verbessert werden würde...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

BM030

Zitat von: Beta-User am 06 Februar 2020, 08:30:40
Ah, ok. Aber dann brauchen wir bei Nutzung dieser Extension den map_data-Zweig eigentlich in dem MQTT2_DEVICE gar nicht, oder?

Bzw. die kann dann so aussehen:
readingList valetudo/rockrobo/map_data:.* {}
(Das MQTT2_DEVICE leitet nichts weiter, das macht der MQTT-Server).

(Wenn die extern erzeugte Karte irgendwie "besser" ist als die interne, wäre es natürlich toll, wenn "unser" code auch verbessert werden würde...)

ja, dann wäre das so.

Nunja, bei der Karte hat man einige nützliche Eigenschaften:

"mapSettings": {
                "drawPath": true,
                "drawCharger": true,
                "drawRobot": true,
                "drawForbiddenZones": true,
                "drawVirtualWalls": true,
                "border": 2,
                "scale": 4,
                "gradientBackground": true,
                "crop_x1": 30,
                "crop_y1": 70,
                "crop_x2": 440,
                "crop_y2": 440
            },


So kann man die Seiten der Karte abschneiden, damit diese nicht unnötige Flächen ausgibt.
Die anderen Optionen erklären sich ja auch.

TomLee

Hallo,

die Größenangaben in devStateIcon greifen bei mir nicht, 256x256 sollte ja quadratisch sein, mein Bild ist rechteckig, egal welche Werte ich verwende.
Habs auch schon mit einer width und height Angabe versucht, greift auch nicht, oder mit nur einem ; ,statt wie im template mit zwei ;  .
Beispiel:
{ '<img style="width:100;height:100;" src="fhem/images/rockrobo_map.svg" >' }

Meine Haus ist lang darum mag ich das Bild drehen, das klappt:
   
{ '<img style="width:100;height:100;transform: rotate(90deg);" src="fhem/images/rockrobo_map.svg" >' }

Zum Verständnis siehe Bilder im Anhang.

Woran liegt das ?




Da ich in der Materie nicht drin bin eine doofe Frage zum RETAIN-Reading im MQTT2_SERVER.
Dass das Reading so extrem lange wird wenn man die Map haben möchte ist nicht vermeidbar ?
Wegen der Länge hab ich es mal als Datei angehängt.

Gruß

Thomas

knueppler

Hallo,

ich verwende die MQTT-Anbindung und bin echt begeistert, vielen Dank für die tolle Arbeit.
Allerdings habe ich ein Problem, seit ich zwei Roborocks eingebunden habe. Nach einiger Zeit verabschiedet sich der MQTT2_CLIENT und ich sehe im Log nur noch
2020.03.21 17:50:32 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.21 17:50:32 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.21 17:51:18 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.21 17:51:18 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.21 17:52:04 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.21 17:52:04 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.21 17:52:50 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.21 17:52:50 1: 192.168.178.144:1883 reappeared (chrisMQTT2)

Abhilfe bringt nur noch ein shutdown restart des FHEM.
Hier noch ein list der Devices
Roborock 1
Internals:
   CID        rockrobo
   DEF        rockrobo
   DEVICETOPIC chrisRobo
   FUUID      5e49060f-f33f-8d80-e420-703e823303b5d021
   FVERSION   10_MQTT2_DEVICE.pm:0.212970/2020-02-27
   IODev      chrisMQTT2
   LASTInputDev chrisMQTT2
   MSGCNT     33
   NAME       chrisRobo
   NR         443
   STATE      docked
   TYPE       MQTT2_DEVICE
   chrisMQTT2_MSGCNT 33
   chrisMQTT2_TIME 2020-03-21 18:13:49
   READINGS:
     2020-03-21 18:13:49   battery_level   98
     2020-03-21 18:13:49   cleanArea       1487.7
     2020-03-21 18:13:49   cleanCount      121
     2020-03-21 18:13:49   cleanTime       24.7
     2020-03-21 17:58:33   command_topic   valetudo/rockrobo/command
     2020-03-21 12:47:06   error           Wheels on top of void, move robot
     2020-03-07 23:15:49   fan_power       set min
     2020-03-21 18:13:49   fan_speed       max
     2020-03-21 17:58:33   fan_speed_list_1 min
     2020-03-21 17:58:33   fan_speed_list_2 medium
     2020-03-21 17:58:33   fan_speed_list_3 high
     2020-03-21 17:58:33   fan_speed_list_4 max
     2020-03-21 17:58:33   fan_speed_list_5 mop
     2020-03-21 18:13:49   filter          125.2
     2020-03-21 17:58:33   json_attributes_topic valetudo/rockrobo/attributes
     2020-03-21 18:13:49   last_run_stats_area 13.9
     2020-03-21 18:13:49   last_run_stats_duration 1055
     2020-03-21 18:13:49   last_run_stats_endTime 1584808649000
     2020-03-21 18:13:49   last_run_stats_errorCode 0
     2020-03-21 18:13:49   last_run_stats_errorDescription No error
     2020-03-21 18:13:49   last_run_stats_finishedFlag true
     2020-03-21 18:13:49   last_run_stats_startTime 1584807594000
     2020-03-21 18:13:49   mainBrush       275.2
     2020-03-21 17:58:32   map_data        Wrote www/images/rockrobo_map.svg
     2020-03-21 17:58:33   name            rockrobo
     2020-03-21 17:58:33   schema          state
     2020-03-21 17:58:33   send_command_topic valetudo/rockrobo/custom_command
     2020-03-21 18:13:49   sensor          5.3
     2020-03-21 17:58:33   set_fan_speed_topic valetudo/rockrobo/set_fan_speed
     2020-03-21 18:13:49   sideBrush       175.2
     2020-03-21 18:13:49   state           docked
     2020-03-21 17:58:33   state_topic     valetudo/rockrobo/state
     2020-03-21 17:58:33   supported_features_1 start
     2020-03-21 17:58:33   supported_features_10 send_command
     2020-03-21 17:58:33   supported_features_2 pause
     2020-03-21 17:58:33   supported_features_3 stop
     2020-03-21 17:58:33   supported_features_4 return_home
     2020-03-21 17:58:33   supported_features_5 battery
     2020-03-21 17:58:33   supported_features_6 status
     2020-03-21 17:58:33   supported_features_7 locate
     2020-03-21 17:58:33   supported_features_8 clean_spot
     2020-03-21 17:58:33   supported_features_9 fan_speed
     2020-03-21 18:13:49   valetudo_state_id 8
     2020-03-21 18:13:49   valetudo_state_name Charging
     2020-03-21 17:07:52   zone            set Vorraum
Attributes:
   IODev      chrisMQTT2
   comment    For original code for "attrTmqtt2_roborock_valetudo2svg()" see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a>. To display generated map seperately, define a weblink device: <br>define valetudo_map weblink htmlCode <img src="fhem/images/rockrobo_map.svg">
   devStateIcon { '<img src="fhem/images/rockrobo_map.svg" style="max-width:256;;max-height:256;;">' }
   group      EG
   icon       vacuum_top
   model      roborock
   readingList homeassistant/vacuum/valetudo_rockrobo/config:.* { json2nameValue($EVENT) }
  valetudo/rockrobo/state:.* { json2nameValue($EVENT) }
  valetudo/rockrobo/attributes:.* { json2nameValue($EVENT) }
  valetudo/rockrobo/map_data:.* {attrTmqtt2_roborock_valetudo2svg("map_data",$EVENT,"www/images/rockrobo_map.svg")}
   room       Esszimmer,Saugbereiche
   setList    start:noArg valetudo/rockrobo/command start
  charge:noArg valetudo/rockrobo/command return_to_base
  stop:noArg valetudo/rockrobo/command stop
  spot:noArg valetudo/rockrobo/command clean_spot
  pause:noArg valetudo/rockrobo/command pause
  locate:noArg valetudo/rockrobo/command locate
  fan_power:min,medium,high,max,mop valetudo/rockrobo/set_fan_speed $EVTPART1
  zone valetudo/rockrobo/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
  goto valetudo/rockrobo/custom_command {"command":"go_to","spot_id":"$EVTPART1"}
  load_map valetudo/rockrobo/custom_command {"command":"load_map","name":"$EVTPART1"}
  store_map valetudo/rockrobo/custom_command {"command":"store_map","name":"$EVTPART1"}
   setStateList charge locate pause stop start


Roborock 2
Internals:
   CID        OGrobo
   DEF        OGrobo
   DEVICETOPIC chrisRoboOG
   FUUID      5e63e821-f33f-8d80-f3b6-2cade6e72e56a985
   FVERSION   10_MQTT2_DEVICE.pm:0.212970/2020-02-27
   IODev      chrisMQTT2
   LASTInputDev chrisMQTT2
   MSGCNT     21
   NAME       chrisRoboOG
   NR         457
   STATE      docked
   TYPE       MQTT2_DEVICE
   chrisMQTT2_MSGCNT 21
   chrisMQTT2_TIME 2020-03-21 18:12:07
   READINGS:
     2020-03-21 18:04:07   battery_level   100
     2020-03-21 18:12:07   cleanArea       298.8
     2020-03-21 18:12:07   cleanCount      23
     2020-03-21 18:12:07   cleanTime       6.4
     2020-03-21 17:58:33   command_topic   valetudo/OGrobo/command
     2020-03-10 13:06:23   error           Wheels on top of void, move robot
     2020-03-07 23:10:26   fan_power       set high
     2020-03-21 18:04:07   fan_speed       medium
     2020-03-21 17:58:33   fan_speed_list_1 min
     2020-03-21 17:58:33   fan_speed_list_2 medium
     2020-03-21 17:58:33   fan_speed_list_3 high
     2020-03-21 17:58:33   fan_speed_list_4 max
     2020-03-21 17:58:33   fan_speed_list_5 mop
     2020-03-21 18:12:07   filter          143.5
     2020-03-21 17:58:33   json_attributes_topic valetudo/OGrobo/attributes
     2020-03-21 18:12:07   last_run_stats_area 17.4
     2020-03-21 18:12:07   last_run_stats_duration 1279
     2020-03-21 18:12:07   last_run_stats_endTime 1584808027000
     2020-03-21 18:12:07   last_run_stats_errorCode 0
     2020-03-21 18:12:07   last_run_stats_errorDescription No error
     2020-03-21 18:12:07   last_run_stats_finishedFlag true
     2020-03-21 18:12:07   last_run_stats_startTime 1584806748000
     2020-03-21 18:12:07   mainBrush       293.5
     2020-03-21 17:58:33   map_data        Wrote www/images/OGrobo_map.svg
     2020-03-21 17:58:33   name            OGrobo
     2020-03-21 17:58:33   schema          state
     2020-03-21 17:58:33   send_command_topic valetudo/OGrobo/custom_command
     2020-03-21 18:12:07   sensor          23.6
     2020-03-21 17:58:33   set_fan_speed_topic valetudo/OGrobo/set_fan_speed
     2020-03-21 18:12:07   sideBrush       193.5
     2020-03-21 18:12:07   state           docked
     2020-03-21 17:58:33   state_topic     valetudo/OGrobo/state
     2020-03-21 17:58:33   supported_features_1 start
     2020-03-21 17:58:33   supported_features_10 send_command
     2020-03-21 17:58:33   supported_features_2 pause
     2020-03-21 17:58:33   supported_features_3 stop
     2020-03-21 17:58:33   supported_features_4 return_home
     2020-03-21 17:58:33   supported_features_5 battery
     2020-03-21 17:58:33   supported_features_6 status
     2020-03-21 17:58:33   supported_features_7 locate
     2020-03-21 17:58:33   supported_features_8 clean_spot
     2020-03-21 17:58:33   supported_features_9 fan_speed
     2020-03-21 18:12:07   valetudo_state_id 8
     2020-03-21 18:12:07   valetudo_state_name Charging
     2020-03-21 17:05:48   zone            set Technikzimmer
Attributes:
   IODev      chrisMQTT2
   comment    For original code for "attrTmqtt2_roborock_valetudo2svg()" see <a href="https://forum.fhem.de/index.php/topic,104687.msg986304.html#msg986304">this forum thread</a>. To display generated map seperately, define a weblink device: <br>define valetudo_map weblink htmlCode <img src="fhem/images/OGrobo_map.svg">
   devStateIcon { '<img src="fhem/images/OGrobo_map.svg" style="max-width:256;;max-height:256;;">' }
   group      OG
   icon       vacuum_top
   model      roborock
   readingList homeassistant/vacuum/valetudo_OGrobo/config:.* { json2nameValue($EVENT) }
  valetudo/OGrobo/state:.* { json2nameValue($EVENT) }
  valetudo/OGrobo/attributes:.* { json2nameValue($EVENT) }
  valetudo/OGrobo/map_data:.* {attrTmqtt2_roborock_valetudo2svg("map_data",$EVENT,"www/images/OGrobo_map.svg")}
   room       Saugbereiche
   setList    start:noArg valetudo/OGrobo/command start
  charge:noArg valetudo/OGrobo/command return_to_base
  stop:noArg valetudo/OGrobo/command stop
  spot:noArg valetudo/OGrobo/command clean_spot
  pause:noArg valetudo/OGrobo/command pause
  locate:noArg valetudo/OGrobo/command locate
  fan_power:min,medium,high,max,mop valetudo/OGrobo/set_fan_speed $EVTPART1
  zone valetudo/OGrobo/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
  goto valetudo/OGrobo/custom_command {"command":"go_to","spot_id":"$EVTPART1"}
  load_map valetudo/OGrobo/custom_command {"command":"load_map","name":"$EVTPART1"}
  store_map valetudo/OGrobo/custom_command {"command":"store_map","name":"$EVTPART1"}
   setStateList charge locate pause stop start


Lieben Dank für Ideen/Hinweise!

Ciao Christian

rudolfkoenig

Der externe MQTT Server schmeisst MQTT2_CLIENT raus, vermutlich haelt sich einer der beiden nicht an dem Standard.

Koenntest du bitte im Problemfall im FHEM die Protokollierung mit "attr chrisMQTT2 verbose 5" fuer ein paar Sekunden erhoehen (zurueckstellen mit "deleteattr chrisMWQTT2 verbose"), und das FHEM-Log fuer die Zeit hier anhaengen? Falls das nicht reicht (und die Wahrscheinlichkeit ist gross), dann braucht man die Logs der anderen Seite auch.

Eine Alternative ist den internen MQTT2_SERVER zu verwenden.

knueppler

Hallo,

eine Sequenz der FHEM- und Mosquitto-Logs
FHEM-Log:
2020.03.22 17:48:25 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.22 17:48:25 5: chrisMQTT2: discarding DISCONNECT (224)(0)
2020.03.22 17:48:25 5: HttpUtils url=http://192.168.178.144:1883/
2020.03.22 17:48:25 4: IP: 192.168.178.144 -> 192.168.178.144
2020.03.22 17:48:25 5: chrisMQTT2: sending CONNECT (16)(24)(0)(6)MQIsdp(3)(2)(0)(30)(0)(10)chrisMQTT2
2020.03.22 17:48:25 5: SW: 101800064d51497364700302001e000a63687269734d51545432
2020.03.22 17:48:25 1: 192.168.178.144:1883 reappeared (chrisMQTT2)


Mosquitto-Log:
1584895658: Socket error on client chrisMQTT2, disconnecting.
1584895658: New connection from 192.168.178.83 on port 1883.
1584895658: New client connected from 192.168.178.83 as chrisMQTT2 (c1, k30).
1584895704: Client chrisMQTT2 has exceeded timeout, disconnecting.


Was mir aufgefallen ist, der BUF des chrisMQTT2 ist nach dem Abbruch unvollständig, man sieht nur einen Teil der Map. U.U. ist das vielleicht das Problem? Mein Haus und damit die Karte ist recht groß:

0��#valetudo/OGrobo/map_data{"header_length":20,"data_length":26649,"version":{"major":1,"minor":0},"map_index":48,"map_sequence":1531,"image":{"position":{"top":199,"left":369},"dimensions":{"height":493,"width":445},"pixels":{"floor":[[185,407],[186,407],[257,407],[258,407],[259,407],[260,407],[261,407],
[262,407],[263,407],[264,407],[265,407],[266,407],[169,406],[170,406],[171,406],
[172,406],[173,406],[174,406],[175,406],[176,406],[177,406],[178,406],[179,406],
[180,406],[181,406],[182,406],[183,406],[184,406],[185,406],[186,406],[258,406],
[259,406],[260,406],[261,406],[262,406],[263,406],[264,406],[265,406],[266,406],
[169,405],[170,405],[171,405],[172,405],[173,405],[174,405],[175,405],[176,405],[177,405],[178,405],[179,405],[180,405],[181,405],[182,40    


Vielen lieben Dank

Christian

rudolfkoenig

Das Umwandeln der Map-Daten in SVG ist CPU-intensiv, wenn ich es richtig in Erinnerung habe, schickt die Firmware diese Daten oft (einmal die Sekunde?), damit duerften 2 Instanzen auch bessere CPUs in schwitzen bringen.
Ich wuerde in valetudo die Map-Daten ausschalten oder nur selten (einmal die Minute oder seltener) senden, falls das nicht moeglich ist oder nicht reicht, dann in FHEM dieses Reading per perl-Ausdruck {undef} ignorieren.

Falls das nicht hilft, dann muessten wir weiter suchen: laut Server Meldung ist FHEM fuer mehr als 45 Sekunden blockiert => ich brauche "attr global verbose 5" Daten fuer ca eine Minute in einem Problemfall.

knueppler

Hallo Rudolf,

danke für die Tipps. FHEM läuft im Docker auf nem MacMini, zwar nicht der neueste, aber der sollte das schon schaffen.
Anyway, ich habe provide map mal auf false gesetzt, tatsächlich ist die nett in FHEM aber nicht nötig.

Ich werden berichten.

Ciao Christian

knueppler

Hallo Rudolf,

ich habe folgende Dinge gemacht.
Im Valetudo provideMapData = false in der config.json, reboot des roborocks, das hat er geflissentlich ignoriert und weiter die Daten geschickt.
Im FHEM attr supressreading map_date durchgeführt, das reading wurde auch nicht mehr geupdated, trotzdem ist das MQTT2_CLIENT gestorben.
Deinen Vorschlag, wie man das Reading abschaltet, konnte ich leider nicht umsetzen, ich habe nicht viel Erfahrung in perl, respektive keine...
Hinweis, ich habe neben dem MQTT2_CLIENT noch ein MQTT-Interface am Laufen um meine Zigbee-Devices zu steuern.
Ich habe nun, wie gewünscht, das Logging von global hochgesetzt und alles rausgefischt, was mit MQTT zu tun hat. Vielleicht siehst Du ja was.
2020.03.28 10:30:44 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.28 10:30:44 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.28 10:30:51 5: Starting notify loop for global, 1 event(s), first is ATTR global verbose 5
....
2020.03.28 10:31:11 5: MQTT MQTT message sent: PingReq/at-most-once
2020.03.28 10:31:11 5: SW: c000
....
2020.03.28 10:31:11 5: MQTT MQTT message received: PingResp/at-most-once
2020.03.28 10:31:11 5: Starting notify loop for MQTT, 1 event(s), first is connection: active
2020.03.28 10:31:11 5: End notify loop for MQTT
....
2020.03.28 10:31:30 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.28 10:31:30 5: Starting notify loop for chrisMQTT2, 1 event(s), first is DISCONNECTED
2020.03.28 10:31:30 5: End notify loop for chrisMQTT2
2020.03.28 10:31:30 5: HttpUtils url=http://192.168.178.144:1883/
2020.03.28 10:31:30 4: IP: 192.168.178.144 -> 192.168.178.144
2020.03.28 10:31:30 5: SW: 101800064d51497364700302001e000a63687269734d51545432
2020.03.28 10:31:30 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.28 10:31:30 5: Starting notify loop for chrisMQTT2, 1 event(s), first is CONNECTED
2020.03.28 10:31:30 5: End notify loop for chrisMQTT2
....
2020.03.28 10:32:14 5: MQTT MQTT message sent: PingReq/at-most-once
2020.03.28 10:32:14 5: SW: c000
2020.03.28 10:32:14 5: Starting notify loop for rr_Christian, 2 event(s), first is durTimerPresence_cr: 864
....
2020.03.28 10:32:14 5: MQTT MQTT message received: PingResp/at-most-once
2020.03.28 10:32:14 5: Starting notify loop for MQTT, 1 event(s), first is connection: active
2020.03.28 10:32:14 5: End notify loop for MQTT
....
2020.03.28 10:32:16 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.28 10:32:16 5: Starting notify loop for chrisMQTT2, 1 event(s), first is DISCONNECTED
2020.03.28 10:32:16 5: End notify loop for chrisMQTT2
2020.03.28 10:32:16 5: HttpUtils url=http://192.168.178.144:1883/
2020.03.28 10:32:16 4: IP: 192.168.178.144 -> 192.168.178.144
2020.03.28 10:32:16 5: SW: 101800064d51497364700302001e000a63687269734d51545432
2020.03.28 10:32:16 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.28 10:32:16 5: Starting notify loop for chrisMQTT2, 1 event(s), first is CONNECTED
2020.03.28 10:32:16 5: End notify loop for chrisMQTT2
....
2020.03.28 10:32:48 5: MQTT MQTT message received: Publish/at-most-once zigbee2mqtt/Garagentuer
  7b 22 63 6f 6e 74 61 63 74 22 3a 74 72 75 65 2c  {"contact":true,
  22 6c 69 6e 6b 71 75 61 6c 69 74 79 22 3a 33 36  "linkquality":36
  2c 22 62 61 74 74 65 72 79 22 3a 31 30 30 2c 22  ,"battery":100,"
  76 6f 6c 74 61 67 65 22 3a 33 30 31 35 7d        voltage":3015}
2020.03.28 10:32:48 5: publish received for zigbee2mqtt/Garagentuer, {"contact":true,"linkquality":36,"battery":100,"voltage":3015}
2020.03.28 10:32:48 5: publish received for zigbee2mqtt/Garagentuer, {"contact":true,"linkquality":36,"battery":100,"voltage":3015}
2020.03.28 10:32:48 5: publish received for zigbee2mqtt/Garagentuer, {"contact":true,"linkquality":36,"battery":100,"voltage":3015}
2020.03.28 10:32:48 5: Starting notify loop for Garagentuer, 1 event(s), first is transmission-state: incoming publish received
2020.03.28 10:32:48 5: Triggering n_Garagentuer
2020.03.28 10:32:48 4: n_Garagentuer exec {
   if ($EVTPART0 eq "open") {
      if (ReadingsVal('Bewegungsmelder', 'brightness', 999) < 120) {
         fhem("set Licht_Garage on-for-timer 300;;");;
      }
   }
}
2020.03.28 10:32:48 5: Cmd: >{
....
2020.03.28 10:33:02 1: 192.168.178.144:1883 disconnected, waiting to reappear (chrisMQTT2)
2020.03.28 10:33:02 5: Starting notify loop for chrisMQTT2, 1 event(s), first is DISCONNECTED
2020.03.28 10:33:02 5: End notify loop for chrisMQTT2
2020.03.28 10:33:02 5: HttpUtils url=http://192.168.178.144:1883/
2020.03.28 10:33:02 4: IP: 192.168.178.144 -> 192.168.178.144
2020.03.28 10:33:02 5: SW: 101800064d51497364700302001e000a63687269734d51545432
2020.03.28 10:33:02 1: 192.168.178.144:1883 reappeared (chrisMQTT2)
2020.03.28 10:33:02 5: Starting notify loop for chrisMQTT2, 1 event(s), first is CONNECTED
2020.03.28 10:33:02 5: End notify loop for chrisMQTT2
....
2020.03.28 10:33:17 5: MQTT MQTT message sent: PingReq/at-most-once
2020.03.28 10:33:17 5: SW: c000
....
2020.03.28 10:33:17 5: MQTT MQTT message received: PingResp/at-most-once
2020.03.28 10:33:17 5: Starting notify loop for MQTT, 1 event(s), first is connection: active
2020.03.28 10:33:17 5: End notify loop for MQTT
....



Vielen lieben Dank, Christian

PS: vielleicht weiß ja einer, wie man im valetudo das Senden der Map abschaltet

rudolfkoenig

ZitatDeinen Vorschlag, wie man das Reading abschaltet, konnte ich leider nicht umsetzen, ich habe nicht viel Erfahrung in perl, respektive keine...
Hat wenig mit perl zu tun, ist Modulspezifisch: in readingList die map Zeile mit
  valetudo/OGrobo/map_data:.* {undef}
ersetzen (OGrobo bei dem anderen Geraet anpassen).

ZitatIch habe nun, wie gewünscht, das Logging von global hochgesetzt und alles rausgefischt, was mit MQTT zu tun hat.
Der Haken mit dem Fischen ist, dass fuer mich nichts mehr uebriggeblieben ist.
Ich habe nach Zeitstempel mit 45 Sekunden Unterschied gesucht, aber da finde ich nur ..., was nach Zensur klingt.
Nach allem was ich sehe, laeuft FHEM ohne Probleme und Verzoegerungen.

Idee: Verbindet sich das MQTT Modul auch zum gleichen Broker? Das mag eine Ursache des Problems sein.

knueppler

Hi,

in der Tat verbindet sich das MQTT-Device mit demselben Broker.
Ich habe dann das Log mal angehängt, in der Hoffnung, Du wirst fündig.
Danke für den Reading-Tipp, manchmal sieht man den Wald vor lauter Bäumen nicht...

Ciao Christian

rudolfkoenig

Ich habe nichts Besonderes gesehen, FHEM ist definitiv zu keiner Zeit laenger blockiert.

Entweder mag der externe MQTT Server MQTT2_CLIENT nicht, oder er ist verwirrt, weil vom gleichen Programm zwei Verbindungen aufgemacht werden (sollte eigentlich nicht sein).
Ich komme ohne sinvolle Infos vom Serverseite nicht weiter.

Ich wuerde (MQTT + MQTT2_CLIENT + externer MQTT-Server) durch MQTT2_SERVER ersetzen, aber ich kann nicht beurteilen, wieviel Aufwand das fuer Dich bedeutet.

knueppler

Guten Morgen,

seit ich das Reading map_date auf {undef} gesetzt habe, momentan keine Probleme, cross your fingers.
Ich gucke mal, dass ich den Log-Level des mosquitto-Servers hochsetzen kann und werde was posten.

Meine momentane Vermutung ist, da sich ja das ganze MQTT2_CLIENT-Device weghängt, dass es mit einem Buffer-Overflow des Devices zu tun hat aufgrund meiner riesigen Karten. Siehe ein paar Posts vorher.
Die Daten werden nicht schnell genug abgeholt und dann wird die nächste ins Nirvana geschrieben und damit ist das Device kaputt, was erst durch einen Reboot bereinigt wird, bis zum nächsten Mal.
Das passiert auch, wenn nur ein Sauger läuft, nur seltener.
Just my 2 cents, es ist gut möglich, dass ich total falsch liege, wundert mich nur, dass es das ganze Device "zerbeamt".

Schönen Sonntag, Christian
Ciao Christian

gameshacker

Hallo,
Ich hoffe es stört nicht, das ich hier nochmal antworte, nutzt jemand die Steuerung des Roboters über MQTT?

Bei der aktuellen Version von Valetudo, bzw. bei der Version 2021.04.0 bereits wurde MQTT in Valetudo neu geschrieben. Nach dem Update war es mir leider nicht möglich, den Sauger über MQTT anzusprechen. Der Sauger wurde zwar erkannt und auch eingerichtet. der Status wurde auch immer aktualisiert, aber Befehle die ich in Fhem rausgegeben habe kamen beim Sauger nicht an.
Ich habe hier einen S5 Roborock und das Protokoll in Valetudo hat gar nicht reagiert.


Ist das evtl. auch schon woanders aufgetreten?

Das Xiaomi Modul funktioniert ohne Probleme.
Laut dem Valetudo Chat, gab es wohl ähnliche Probleme in HA und da mussten die Automations angepasst werden.

Ich bin nun wieder auf eine alte Valetudo Version zurück, damit es klappt, kann aber gerne bei bedarf den sauger neu flashen und testen.

laberlaib

Gude.

Ich habe heute auf meinem V1 alles neu installiert - via OTA geht das ja sowas von unkompliziert.
Danach ging auch nichts mehr per MQTT, dann habe ich gegoogelt und für die neue MQTT-Ansteuerung gilt nun folgendens:

https://valetudo.cloud/pages/integrations/mqtt.html#operationoperation

D.h. die Befehle/Topics haben sich geändert.
Alt, aus attrTemplate
start:noArg valetudo/NeatBlushingSwallow/BasicControlCapability/operation/set START
  charge:noArg valetudo/NeatBlushingSwallow/command return_to_base
  stop:noArg valetudo/NeatBlushingSwallow/command stop
  spot:noArg valetudo/NeatBlushingSwallow/command clean_spot
  pause:noArg valetudo/NeatBlushingSwallow/command pause
  locate:noArg valetudo/NeatBlushingSwallow/command locate
  fan_power:min,medium,high,max,mop valetudo/NeatBlushingSwallow/set_fan_speed $EVTPART1
  zone valetudo/NeatBlushingSwallow/custom_command {"command":"zoned_cleanup","zone_ids":["$EVTPART1"]}
  goto valetudo/NeatBlushingSwallow/custom_command {"command":"go_to","spot_id":"$EVTPART1"}
  load_map valetudo/NeatBlushingSwallow/custom_command {"command":"load_map","name":"$EVTPART1"}
  store_map valetudo/NeatBlushingSwallow/custom_command {"command":"store_map","name":"$EVTPART1"}


Neu:
start:noArg valetudo/NeatBlushingSwallow/BasicControlCapability/operation/set START
  charge:noArg valetudo/NeatBlushingSwallow/BasicControlCapability/operation/set HOME
  stop:noArg valetudo/NeatBlushingSwallow/BasicControlCapability/operation/set STOP
  pause:noArg valetudo/NeatBlushingSwallow/BasicControlCapability/operation/set PAUSE


Disclaimer: Ich hab nur die Basicoperations beschrieben und davon auch nur START einmal ausprobiert.
Die anderen brauche ich bei meinem V1 (noch) nicht, da der ja eh die Karte nicht speichern kann etc.

XiaomiDevice läuft bei mir gerade gar nicht mehr, auch schade.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)