Von MQTT2_SERVER verschickte Nachrichten mit type "reserved"

krikan · 21 Oktober 2019, 21:19:21

Hallo!

Habe einen gerooteten Staubsauger mit dem aktuellen https://github.com/Hypfer/Valetudo 0.4 bestückt und MQTT auf dem Sauger aktiviert. Die vom MQTT2_SERVER verschickten MQTT-Nachrichten lassen Valetudo mit MQTT auf dem Sauger reproduzierbar abstürzen. Nach https://github.com/Hypfer/Valetudo/issues/134#issuecomment-511531783 werden die Abstürze auf die Nachrichten von FHEM mit "reserved"-Flags zurückgeführt. Für Valetudo gibt es mittlerweile einen Patch, der das Problem beheben soll.

Obwohl ich aus der Diskussion bei Valetudo interpretiere, dass FHEM "falsche" Nachrichten verschickt, kann ich das anhand des obigen Github-Issuses und den dortigen Infos nicht nachvollziehen. Für mich sehen alle FHEM-MQTT-Nachrichten korrekt aus.

Blöderweise kann ich anhand der Valetudo-Logs nicht erkennen, welche FHEM-MQTT-Nachrichten das Problem auslösen. Tippe auf SUBSCRIBE, da es 11 Fehler in Valetudo bis zum Absturz gibt.

Kann mir jemand erklären, wo das Problem bei den FHEM-MQTT-Nachrichten ist? Da das Problem durch Valetudo durch Patch behobem wurde, ist das hier ein eher akademisches Thema; aber ich würde gerne das MQTT-Protokoll verstehen und wissen, auf welcher Seite (FHEM oder Valetudo) die Ursache liegt.

Gruß, Christian

verbose 5-Log von FHEM bis zum Absturz von Valetudo:

Code Auswählen

2019.10.21 20:27:05.782 4: Connection accepted from fhemMqtt_192.168.188.46_54219
2019.10.21 20:27:05.801 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_6eba03a8
2019.10.21 20:27:05.802 4: fhemMqtt_192.168.188.46_54219 mqttjs_6eba03a8 CONNECT V:4 keepAlive:60
2019.10.21 20:27:05.849 5: SUBSCRIBE: (130)c(154)^(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:05.849 4: fhemMqtt_192.168.188.46_54219 mqttjs_6eba03a8 SUBSCRIBE
2019.10.21 20:27:05.850 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:05.850 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:05.850 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:05.893 4: Connection closed for fhemMqtt_192.168.188.46_54219: EOF
2019.10.21 20:27:08.709 4: Connection accepted from fhemMqtt_192.168.188.46_54221
2019.10.21 20:27:08.745 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_847aa466
2019.10.21 20:27:08.746 4: fhemMqtt_192.168.188.46_54221 mqttjs_847aa466 CONNECT V:4 keepAlive:60
2019.10.21 20:27:08.787 5: SUBSCRIBE: (130)c(9)&(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:08.788 4: fhemMqtt_192.168.188.46_54221 mqttjs_847aa466 SUBSCRIBE
2019.10.21 20:27:08.788 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:08.788 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:08.788 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:08.836 4: Connection closed for fhemMqtt_192.168.188.46_54221: EOF
2019.10.21 20:27:11.770 4: Connection accepted from fhemMqtt_192.168.188.46_54233
2019.10.21 20:27:11.790 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_ea895da2
2019.10.21 20:27:11.790 4: fhemMqtt_192.168.188.46_54233 mqttjs_ea895da2 CONNECT V:4 keepAlive:60
2019.10.21 20:27:11.838 5: SUBSCRIBE: (130)c_g(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:11.838 4: fhemMqtt_192.168.188.46_54233 mqttjs_ea895da2 SUBSCRIBE
2019.10.21 20:27:11.838 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:11.839 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:11.839 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:11.882 4: Connection closed for fhemMqtt_192.168.188.46_54233: EOF
2019.10.21 20:27:14.716 4: Connection accepted from fhemMqtt_192.168.188.46_54235
2019.10.21 20:27:14.752 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_e9ff2f91
2019.10.21 20:27:14.753 4: fhemMqtt_192.168.188.46_54235 mqttjs_e9ff2f91 CONNECT V:4 keepAlive:60
2019.10.21 20:27:14.799 5: SUBSCRIBE: (130)c(202)(241)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:14.799 4: fhemMqtt_192.168.188.46_54235 mqttjs_e9ff2f91 SUBSCRIBE
2019.10.21 20:27:14.800 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:14.800 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:14.800 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:14.869 4: Connection closed for fhemMqtt_192.168.188.46_54235: EOF
2019.10.21 20:27:17.691 4: Connection accepted from fhemMqtt_192.168.188.46_54236
2019.10.21 20:27:17.710 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_df6285f1
2019.10.21 20:27:17.711 4: fhemMqtt_192.168.188.46_54236 mqttjs_df6285f1 CONNECT V:4 keepAlive:60
2019.10.21 20:27:17.749 5: SUBSCRIBE: (130)c(231)f(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:17.749 4: fhemMqtt_192.168.188.46_54236 mqttjs_df6285f1 SUBSCRIBE
2019.10.21 20:27:17.749 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:17.749 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:17.750 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:17.792 4: Connection closed for fhemMqtt_192.168.188.46_54236: EOF
2019.10.21 20:27:20.590 4: Connection accepted from fhemMqtt_192.168.188.46_54237
2019.10.21 20:27:20.609 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_c1cb4628
2019.10.21 20:27:20.610 4: fhemMqtt_192.168.188.46_54237 mqttjs_c1cb4628 CONNECT V:4 keepAlive:60
2019.10.21 20:27:20.647 5: SUBSCRIBE: (130)c(229)=(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:20.648 4: fhemMqtt_192.168.188.46_54237 mqttjs_c1cb4628 SUBSCRIBE
2019.10.21 20:27:20.648 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:20.648 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:20.648 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:20.691 4: Connection closed for fhemMqtt_192.168.188.46_54237: EOF
2019.10.21 20:27:23.487 4: Connection accepted from fhemMqtt_192.168.188.46_54238
2019.10.21 20:27:23.524 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_243d2d09
2019.10.21 20:27:23.525 4: fhemMqtt_192.168.188.46_54238 mqttjs_243d2d09 CONNECT V:4 keepAlive:60
2019.10.21 20:27:23.566 5: SUBSCRIBE: (130)c(144)i(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:23.566 4: fhemMqtt_192.168.188.46_54238 mqttjs_243d2d09 SUBSCRIBE
2019.10.21 20:27:23.566 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:23.566 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:23.567 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:23.610 4: Connection closed for fhemMqtt_192.168.188.46_54238: EOF
2019.10.21 20:27:26.395 4: Connection accepted from fhemMqtt_192.168.188.46_54239
2019.10.21 20:27:26.432 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_2d44c263
2019.10.21 20:27:26.433 4: fhemMqtt_192.168.188.46_54239 mqttjs_2d44c263 CONNECT V:4 keepAlive:60
2019.10.21 20:27:26.474 5: SUBSCRIBE: (130)c(131)(226)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:26.475 4: fhemMqtt_192.168.188.46_54239 mqttjs_2d44c263 SUBSCRIBE
2019.10.21 20:27:26.475 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:26.475 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:26.476 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:26.522 4: Connection closed for fhemMqtt_192.168.188.46_54239: EOF
2019.10.21 20:27:28.094 3: TRX_WEATHER: Unknown device TFATS34C_9, please define it
2019.10.21 20:27:29.352 4: Connection accepted from fhemMqtt_192.168.188.46_54240
2019.10.21 20:27:29.371 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_1aaaa765
2019.10.21 20:27:29.371 4: fhemMqtt_192.168.188.46_54240 mqttjs_1aaaa765 CONNECT V:4 keepAlive:60
2019.10.21 20:27:29.409 5: SUBSCRIBE: (130)c(233)(213)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:29.410 4: fhemMqtt_192.168.188.46_54240 mqttjs_1aaaa765 SUBSCRIBE
2019.10.21 20:27:29.410 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:29.410 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:29.410 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:29.453 4: Connection closed for fhemMqtt_192.168.188.46_54240: EOF
2019.10.21 20:27:32.220 4: Connection accepted from fhemMqtt_192.168.188.46_54241
2019.10.21 20:27:32.239 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_787a6590
2019.10.21 20:27:32.240 4: fhemMqtt_192.168.188.46_54241 mqttjs_787a6590 CONNECT V:4 keepAlive:60
2019.10.21 20:27:32.278 5: SUBSCRIBE: (130)c(253)(185)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:32.278 4: fhemMqtt_192.168.188.46_54241 mqttjs_787a6590 SUBSCRIBE
2019.10.21 20:27:32.278 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:32.278 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:32.278 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:32.321 4: Connection closed for fhemMqtt_192.168.188.46_54241: EOF
2019.10.21 20:27:35.135 4: Connection accepted from fhemMqtt_192.168.188.46_54242
2019.10.21 20:27:35.215 5: CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_333ea0b7
2019.10.21 20:27:35.216 4: fhemMqtt_192.168.188.46_54242 mqttjs_333ea0b7 CONNECT V:4 keepAlive:60
2019.10.21 20:27:35.256 5: SUBSCRIBE: (130)c(159)o(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.21 20:27:35.256 4: fhemMqtt_192.168.188.46_54242 mqttjs_333ea0b7 SUBSCRIBE
2019.10.21 20:27:35.256 4:   topic:valetudo/rockrobo/command qos:0
2019.10.21 20:27:35.256 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.21 20:27:35.256 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.21 20:27:35.300 4: Connection closed for fhemMqtt_192.168.188.46_54242: EOF

rudolfkoenig · 21 Oktober 2019, 23:34:37

Leider protokolliert MQTT2_SERVER nur die Eingangsseite sehr detailliert, nicht die Antworten.

Soweit ich sehe, verschickt MQTT2_SERVER "nur" Nachrichten der Sorte CONNACK, PUBACK, SUBACK, UNSUBACK, PINGRESP, PUBLISH.
Der verlinkte Beitrag verweist auf die Tabelle 2.2 im RFC, die wiederum besagt, dass im Kommandobyte das zweite Nibble bis auf PUBLISH 0 sein muss (== reserviert), bei PUBLISH 0 sein darf.
MQTT2_SERVER versendet alle Nachrichten mit 0 im zweiten Nibble des Kommandobytes, siehe die addToWritebuffer Zeilen in MQTT2_SERVER.

Ich vermute eher ein Laengenkodierungsproblem, entweder in MQTT2_SERVER oder in Valudo.

Da ich an einem Fix interessiert bin, habe ich gerade eine Version eingecheckt, was auch die Ausgangsseite detailliert protokolliert.
Wenn das Problem noch reproduzierbar ist, bin ich an einem erneuten Dump interessiert.

krikan · 22 Oktober 2019, 02:02:00

Log mit geänderter Modulversion:

Code Auswählen

2019.10.22 01:28:56.734 4: Connection accepted from fhemMqtt_192.168.188.46_55680
2019.10.22 01:28:56.772 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_e0418ba5
2019.10.22 01:28:56.773 4:   fhemMqtt_192.168.188.46_55680 mqttjs_e0418ba5 CONNECT V:4 keepAlive:60
2019.10.22 01:28:56.773 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:28:56.815 5: in:  SUBSCRIBE: (130)c(132)(198)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:28:56.815 4:   fhemMqtt_192.168.188.46_55680 mqttjs_e0418ba5 SUBSCRIBE
2019.10.22 01:28:56.815 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:28:56.816 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:28:56.816 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:28:56.816 5: out: SUBACK: (144)(3)(132)(198)(0)(0)(0)
2019.10.22 01:28:56.862 4: Connection closed for fhemMqtt_192.168.188.46_55680: EOF
2019.10.22 01:28:59.629 4: Connection accepted from fhemMqtt_192.168.188.46_55682
2019.10.22 01:28:59.678 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_20e93af4
2019.10.22 01:28:59.679 4:   fhemMqtt_192.168.188.46_55682 mqttjs_20e93af4 CONNECT V:4 keepAlive:60
2019.10.22 01:28:59.679 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:28:59.721 5: in:  SUBSCRIBE: (130)c(245)z(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:28:59.721 4:   fhemMqtt_192.168.188.46_55682 mqttjs_20e93af4 SUBSCRIBE
2019.10.22 01:28:59.721 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:28:59.722 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:28:59.722 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:28:59.722 5: out: SUBACK: (144)(3)(245)z(0)(0)(0)
2019.10.22 01:28:59.770 4: Connection closed for fhemMqtt_192.168.188.46_55682: EOF
2019.10.22 01:29:02.652 4: Connection accepted from fhemMqtt_192.168.188.46_55683
2019.10.22 01:29:02.699 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_8bd699c7
2019.10.22 01:29:02.700 4:   fhemMqtt_192.168.188.46_55683 mqttjs_8bd699c7 CONNECT V:4 keepAlive:60
2019.10.22 01:29:02.700 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:02.745 5: in:  SUBSCRIBE: (130)czK(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:02.745 4:   fhemMqtt_192.168.188.46_55683 mqttjs_8bd699c7 SUBSCRIBE
2019.10.22 01:29:02.746 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:02.746 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:02.746 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:02.747 5: out: SUBACK: (144)(3)zK(0)(0)(0)
2019.10.22 01:29:02.801 4: Connection closed for fhemMqtt_192.168.188.46_55683: EOF
2019.10.22 01:29:05.582 4: Connection accepted from fhemMqtt_192.168.188.46_55684
2019.10.22 01:29:05.628 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_82f1f5d4
2019.10.22 01:29:05.629 4:   fhemMqtt_192.168.188.46_55684 mqttjs_82f1f5d4 CONNECT V:4 keepAlive:60
2019.10.22 01:29:05.629 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:05.669 5: in:  SUBSCRIBE: (130)c(188)(179)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:05.669 4:   fhemMqtt_192.168.188.46_55684 mqttjs_82f1f5d4 SUBSCRIBE
2019.10.22 01:29:05.669 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:05.669 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:05.670 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:05.670 5: out: SUBACK: (144)(3)(188)(179)(0)(0)(0)
2019.10.22 01:29:05.716 4: Connection closed for fhemMqtt_192.168.188.46_55684: EOF
2019.10.22 01:29:08.631 4: Connection accepted from fhemMqtt_192.168.188.46_55685
2019.10.22 01:29:08.679 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_21d5fdf3
2019.10.22 01:29:08.680 4:   fhemMqtt_192.168.188.46_55685 mqttjs_21d5fdf3 CONNECT V:4 keepAlive:60
2019.10.22 01:29:08.680 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:08.725 5: in:  SUBSCRIBE: (130)c(8))(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:08.725 4:   fhemMqtt_192.168.188.46_55685 mqttjs_21d5fdf3 SUBSCRIBE
2019.10.22 01:29:08.726 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:08.726 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:08.726 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:08.727 5: out: SUBACK: (144)(3)(8))(0)(0)(0)
2019.10.22 01:29:08.775 4: Connection closed for fhemMqtt_192.168.188.46_55685: EOF
2019.10.22 01:29:11.107 3: TRX_WEATHER: Unknown device TFATS34C_9, please define it
2019.10.22 01:29:11.636 4: Connection accepted from fhemMqtt_192.168.188.46_55686
2019.10.22 01:29:11.656 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_0d85bfbd
2019.10.22 01:29:11.657 4:   fhemMqtt_192.168.188.46_55686 mqttjs_0d85bfbd CONNECT V:4 keepAlive:60
2019.10.22 01:29:11.657 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:11.694 5: in:  SUBSCRIBE: (130)c(221)%(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:11.694 4:   fhemMqtt_192.168.188.46_55686 mqttjs_0d85bfbd SUBSCRIBE
2019.10.22 01:29:11.694 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:11.694 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:11.695 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:11.695 5: out: SUBACK: (144)(3)(221)%(0)(0)(0)
2019.10.22 01:29:11.740 4: Connection closed for fhemMqtt_192.168.188.46_55686: EOF
2019.10.22 01:29:14.550 4: Connection accepted from fhemMqtt_192.168.188.46_55687
2019.10.22 01:29:14.598 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_a01e9d8f
2019.10.22 01:29:14.599 4:   fhemMqtt_192.168.188.46_55687 mqttjs_a01e9d8f CONNECT V:4 keepAlive:60
2019.10.22 01:29:14.599 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:14.640 5: in:  SUBSCRIBE: (130)c(138)(144)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:14.640 4:   fhemMqtt_192.168.188.46_55687 mqttjs_a01e9d8f SUBSCRIBE
2019.10.22 01:29:14.641 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:14.641 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:14.641 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:14.641 5: out: SUBACK: (144)(3)(138)(144)(0)(0)(0)
2019.10.22 01:29:14.687 4: Connection closed for fhemMqtt_192.168.188.46_55687: EOF
2019.10.22 01:29:17.484 4: Connection accepted from fhemMqtt_192.168.188.46_55688
2019.10.22 01:29:17.530 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_9c3db279
2019.10.22 01:29:17.531 4:   fhemMqtt_192.168.188.46_55688 mqttjs_9c3db279 CONNECT V:4 keepAlive:60
2019.10.22 01:29:17.531 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:17.572 5: in:  SUBSCRIBE: (130)c(255)(210)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:17.572 4:   fhemMqtt_192.168.188.46_55688 mqttjs_9c3db279 SUBSCRIBE
2019.10.22 01:29:17.572 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:17.573 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:17.573 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:17.573 5: out: SUBACK: (144)(3)(255)(210)(0)(0)(0)
2019.10.22 01:29:17.619 4: Connection closed for fhemMqtt_192.168.188.46_55688: EOF
2019.10.22 01:29:20.518 4: Connection accepted from fhemMqtt_192.168.188.46_55689
2019.10.22 01:29:20.568 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_a71d7042
2019.10.22 01:29:20.569 4:   fhemMqtt_192.168.188.46_55689 mqttjs_a71d7042 CONNECT V:4 keepAlive:60
2019.10.22 01:29:20.569 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:20.613 5: in:  SUBSCRIBE: (130)c(211)7(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:20.613 4:   fhemMqtt_192.168.188.46_55689 mqttjs_a71d7042 SUBSCRIBE
2019.10.22 01:29:20.613 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:20.614 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:20.614 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:20.614 5: out: SUBACK: (144)(3)(211)7(0)(0)(0)
2019.10.22 01:29:20.661 4: Connection closed for fhemMqtt_192.168.188.46_55689: EOF
2019.10.22 01:29:23.562 4: Connection accepted from fhemMqtt_192.168.188.46_55690
2019.10.22 01:29:23.609 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_aaaa007d
2019.10.22 01:29:23.609 4:   fhemMqtt_192.168.188.46_55690 mqttjs_aaaa007d CONNECT V:4 keepAlive:60
2019.10.22 01:29:23.610 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:23.655 5: in:  SUBSCRIBE: (130)cY(183)(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:23.656 4:   fhemMqtt_192.168.188.46_55690 mqttjs_aaaa007d SUBSCRIBE
2019.10.22 01:29:23.656 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:23.656 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:23.656 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:23.656 5: out: SUBACK: (144)(3)Y(183)(0)(0)(0)
2019.10.22 01:29:23.705 4: Connection closed for fhemMqtt_192.168.188.46_55690: EOF
2019.10.22 01:29:26.455 4: Connection accepted from fhemMqtt_192.168.188.46_55692
2019.10.22 01:29:26.502 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_f26c8022
2019.10.22 01:29:26.503 4:   fhemMqtt_192.168.188.46_55692 mqttjs_f26c8022 CONNECT V:4 keepAlive:60
2019.10.22 01:29:26.504 5: out: CONNACK:  (2)(0)(0)
2019.10.22 01:29:26.546 5: in:  SUBSCRIBE: (130)cIL(0)(25)valetudo/rockrobo/command(0)(0)(31)valetudo/rockrobo/set_fan_speed(0)(0) valetudo/rockrobo/custom_command(0)
2019.10.22 01:29:26.547 4:   fhemMqtt_192.168.188.46_55692 mqttjs_f26c8022 SUBSCRIBE
2019.10.22 01:29:26.547 4:   topic:valetudo/rockrobo/command qos:0
2019.10.22 01:29:26.547 4:   topic:valetudo/rockrobo/set_fan_speed qos:0
2019.10.22 01:29:26.548 4:   topic:valetudo/rockrobo/custom_command qos:0
2019.10.22 01:29:26.548 5: out: SUBACK: (144)(3)IL(0)(0)(0)
2019.10.22 01:29:26.594 4: Connection closed for fhemMqtt_192.168.188.46_55692: EOF

krikan · 22 Oktober 2019, 03:18:11

Brauche wohl einen Grundlagenkurs in MQTT-Nachrichten. Wenn ich die FHEM-Nachrichten nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html betrachte, dann habe ich Verständnisprobleme.

Code Auswählen

2019.10.22 01:28:56.773 5: out: CONNACK: (2)(0)(0)
Nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718033 fehlt im Log das 1. Byte des Fixed Header (32).
Ich hätte die Nachricht zusammengebaut:

Code Auswählen

(32) (2) (0) (0)

Code Auswählen

2019.10.22 01:28:56.816 5: out: SUBACK: (144)(3)(132)(198)(0)(0)(0)
Nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718068 ist das 2. Byte des Fixed Header die "Remaining Length". Bei einer "Remaining Length" von (3) verstehe ich die letzten beiden Bytes (0) (0) im Log nicht. Wofür stehen die bzw. sind die zuviel?
Hier hätte ich folgende Nachricht gebildet:

Code Auswählen

(144) (3) (132) (198) (0)

Ist eventuell das von mir gewählte Dokument http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html falsch? Muss ich woanders nachschauen?

rudolfkoenig · 22 Oktober 2019, 11:00:24

ZitatNach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718033 fehlt im Log das 1. Byte des Fixed Header (32).

Fehlt nicht, ist aber druckbar (Leerzeichen), deswegen tarnt es sich gut.
Habe eine Weile ueberlegt, bin aber immer noch dafuer, es dabei zu belassen.

ZitatBei einer "Remaining Length" von (3) verstehe ich die letzten beiden Bytes (0) (0) im Log nicht.

Vielen Dank fuer die hoefliche Formulierung

, das ist wohl auch die Ursache des Problems: (0)(0) Als Nachricht ist nicht erlaubt.
Ich habe den Fehler behoben, kann es aber nicht testen, da ich keinen Client kenne, der mehrere topics in eine Subscribe Nachricht zusammenfasst.

krikan · 22 Oktober 2019, 11:43:29

Zitat von: rudolfkoenig am 22 Oktober 2019, 11:00:24
Fehlt nicht, ist aber druckbar (Leerzeichen), deswegen tarnt es sich gut.

Bedeutet das, dass ich nur das Log nicht richtig lese/verstehe: statt (32) ist eben ein "gedrucktes" Leerzeichen im Log!?

ZitatHabe eine Weile ueberlegt, bin aber immer noch dafuer, es dabei zu belassen.

Kein Problem. Wenn man es kennt, dann ist es ok.

ZitatVielen Dank fuer die hoefliche Formulierung

Ich beschäftige mich genau seit gestern mit MQTT, darum bin ich froh, wenn ich nicht total falsch interpretiere.

ZitatIch habe den Fehler behoben, kann es aber nicht testen, da ich keinen Client kenne, der mehrere topics in eine Subscribe Nachricht zusammenfasst.

Tests mache ich; will MQTT ja für den Sauger nutzen. (Bisher wurden noch keine MQTT2_DEVICES -Devices per autocreate erzeugt; das muss ich noch verstehen.)

rudolfkoenig · 22 Oktober 2019, 11:59:20

Zitatstatt (32) ist eben ein "gedrucktes" Leerzeichen im Log!?

Ja, zwei Leerzeichen zwischen : und ( bei CONNACK. Man muesste Header und Topic/Message anders behandeln, die debug Routine weiss aber nicht, was Header ist => Umbau waere zu aufwendig.

ZitatBisher wurden noch keine MQTT2_DEVICES -Devices per autocreate erzeugt; das muss ich noch verstehen.

Wird erst beim Eintreffen von MQTT-Nachrichten erzeugt, es muss ein autocreate Device existieren, und das autocreate Attribut fuer MQTT2_SERVER sollte nicht auf no stehen.

Otto123 · 22 Oktober 2019, 12:02:03

Zitat von: krikan am 22 Oktober 2019, 11:43:29
Ich beschäftige mich genau seit gestern mit MQTT, darum bin ich froh, wenn ich nicht total falsch interpretiere.
Tests mache ich; will MQTT ja für den Sauger nutzen. (Bisher wurden noch keine MQTT2_DEVICES -Devices per autocreate erzeugt; das muss ich noch verstehen.)

Mir geht es wie Dir, ok seit 14 Tagen aber nur lückenhaft. Deswegen lese ich interessiert mit

Zusätzlich zu Rudis Aussage:

Das autocreate hängt nach meiner Erkenntnis an der CID, in einer pub Message

Code Auswählen

mosquitto_pub -h raspib2 -i COMPUTER -t /pi/CPU/raspib/temperature -m 22
erzeugt ein Device.
Lässt Du - i COMPUTER weg passiert es nicht

Gruß Otto

rudolfkoenig · 22 Oktober 2019, 12:11:41

ZitatLässt Du - i COMPUTER weg passiert es nicht

Ja, weil MQTT2_DEVICE extra Code fuer mosquitto_pub hat, der ohne -i immer andere ClientIDs schickt.

krikan · 22 Oktober 2019, 13:31:29

Mit der geänderten MQTT2-SERVER gibt es keinen Absturz von Valetudo auf dem Sauger mehr. Das (knappe) Valetudo-Log ist bisher ebenfalls ohne Fehlermeldungen. Aus meiner Sicht alles Bestens.

Zitat von: rudolfkoenig am 22 Oktober 2019, 11:59:20
Wird erst beim Eintreffen von MQTT-Nachrichten erzeugt, es muss ein autocreate Device existieren, und das autocreate Attribut fuer MQTT2_SERVER sollte nicht auf no stehen.

Funktioniert jetzt. Rahmenbedingungen waren vorher auch erfüllt, aber der Absturz war wohl zu früh!?

Ansonsten muss ich jetzt erst mal lesen...

krikan · 22 Oktober 2019, 19:24:11

Jetzt verursacht zwar FHEM keinen Absturz von Valetuo mehr, aber Valetudo bringt -mit zugegeben etwas längeren MQTT-Nachrichten- fhem.pl zum "erliegen". fhem.pl zieht nach diesen Nachrichten laut "top" 100% der CPU-Leistung. Fängt sich aber auch nach bis zu einer halben Stunde nicht. Das habe ich jetzt mehrmals erlebt; meistens habe ich nur bis zu 5 Minuten gewartet und fhem.pl dann "gekillt".

Letzte Zeilen im Log eines Beispiels habe ich angehängt, da es für code-Tags zu lang ist. Es gibt auch noch längere Nachrichten wie "data_length":28718.

rudolfkoenig · 22 Oktober 2019, 21:03:45

- die Nachricht aus dem Log ist 283776 Bytes lang und beinhaltet vmtl. ein Bitmap
- ich kriege es mit mosquitto_pub weder unter Linux, noch unter OSX verschickt (Argument list too long)
- als mosquitto_pub Ersatz habe ich jetzt eine minimalistische FHEM Konfiguration gebaut, mit MQTT2_CLIENT
- das MQTT autocreate, in speziellen json2nameValue ist nicht fuer Bilder im JSON-Format optimiert: auch wenn es (vmtl.?) in einigen Minuten durch ist, werden ca 60.000 Readings, und entsprechend viele Events generiert (pro gesetzten Pixel 2, fuer X und fuer Y).
- ich habe MQTT2_DEVICE gerade angepasst: ab sofort muss fuer das automatisch angelegte json2nameValue die Nachricht kleiner als 10k sein.
- als Workaround kann man mit der "alten" Code readingList mit "mqttjs_b3bf0259:valetudo/rockrobo/map_data:.* map_data" ergaenzen und/oder "attr mqttjs_b3bf0259 autocreate 0" setzen.
- idealerweise baut jemand eine valetudo2png() Funktion

krikan · 23 Oktober 2019, 07:11:03

Zitat von: Otto123 am 22 Oktober 2019, 12:02:03
Mir geht es wie Dir, ok seit 14 Tagen aber nur lückenhaft. Deswegen lese ich interessiert mit

Meine Frustrationsgrenze ist bald erreicht. Habe mir wohl nicht das ideale Einstiegsobjekt ausgesucht, da Valetudo-MQTT-Doku recht verstreut lliegt bzw. sich nur aus .js-Code im Detail erschließt. (Oder ich finde es nur nicht). Aber ihr könnt mich am 2.11. in Hambug ja aufbauen.

Zitat von: rudolfkoenig am 22 Oktober 2019, 21:03:45
die Nachricht aus dem Log[...] beinhaltet vmtl. ein Bitmap

Ja, Bitmap

Zitat
- ich kriege es mit mosquitto_pub weder unter Linux, noch unter OSX verschickt (Argument list too long)

Hätte erwartet, dass bei mosquitto_pub "-f file" das Längenproblem löst.

Zitat- das MQTT autocreate, in speziellen json2nameValue ist nicht fuer Bilder im JSON-Format optimiert: auch wenn es (vmtl.?) in einigen Minuten durch ist, werden ca 60.000 Readings, und entsprechend viele Events generiert (pro gesetzten Pixel 2, fuer X und fuer Y).
- ich habe MQTT2_DEVICE gerade angepasst: ab sofort muss fuer das automatisch angelegte json2nameValue die Nachricht kleiner als 10k sein.
- als Workaround kann man mit der "alten" Code readingList mit "mqttjs_b3bf0259:valetudo/rockrobo/map_data:.* map_data" ergaenzen und/oder "attr mqttjs_b3bf0259 autocreate 0" setzen.

Danke im Nachhinein betrachtet, hätte ich auch selbst darauf kommen können. Ist wohl zuviel Unbekanntes auf eine Haufen.
"In einigen Minuten durch.." -> habe einmal tatsächlich ein halbe Stunde gewartet und es war noch nicht durch. Aber ich nutze auch nur einen (sonst ausreichenden Raspi 1 zum Experimentieren und keine Workstation.

Zitat- idealerweise baut jemand eine valetudo2png() Funktion

Dann warten wir mal ab...

Otto123 · 23 Oktober 2019, 09:01:20

Hast Du wegen Valetudo auch den Staubsauger Thread verfolgt? Ich meine dort mit gelesen zu haben, dass die Karte nur über einen Link verwendet wird. Und irgendwo anders ging es hier auch schon mal um die Verschickung von png Bildern über mqtt... Hilft Dir jetzt auch nicht

herrmannj · 23 Oktober 2019, 09:14:44

Aufbau: sehr gern! Bin auch erst vor 2-3 Wochen tiefer in mqtt eingestiegen und mache ganz andere Erfahrungen. Bin sehr begeistert, auch von Rudi s Implementierung. Ich denke der Staubsauger ist einfach ein blöder Einstieg ...

Vg joerg

rudolfkoenig · 23 Oktober 2019, 15:09:32

ZitatDann warten wir mal ab...

Wenn man Folgendes:

Code Auswählen

sub
valetudo2svg($$$)
{
  my ($reading, $d, $filename) = @_;
  my %ret;

  if($d !~ m/height":(\d+),"width":(\d+).*?floor":\[(.*\])\]/) {
    $ret{$reading} = "ERROR: Unknown format";
    return \%ret;
  }
  my ($w,$h,$nums) = ($1, $2, $3);

  my $svg=<<"EOD";
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg version="1.0" xmlns="http://www.w3.org/2000/svg" width="$w" height="$h" viewBox="0 0 $w $h">
<g fill="#000000" stroke="none">
  <rect x="0" y="0" width="$w" height="$h" stroke="black" stroke-width="1" fill="none"/>
EOD

  $nums =~ s/\[(\d+),(\d+)\]/
    $svg .= "<rect x=\"$1\" y=\"$2\" width=\"1\" height=\"1\"\/>\n";
    ""
  /xge;
  $svg .= "</g></svg>";

  if(!open FD,">$filename") {
    $ret{$reading} = "ERROR: $filename: $!";
    return \%ret;
  }
  print FD $svg;
  close(FD);
  $ret{$reading} = "Wrote $filename";
  return \%ret;
}

in 99_myUtils.pm aufnimmt, und readingList der MQTT device mit

Code Auswählen

valetudo/rockrobo/map_data:.* {valetudo2svg("map_data",$EVENT,"www/images/valetudo_map.svg")}ergaenzt, dann kann man mit

Code Auswählen

define valetudo_map weblink htmlCode <img src="fhem/images/valetudo_map.svg">das Bitmap anzeigen.

Zu meinem Verstaendnis: wann werden welche Bitmaps gesendet?

Beta-User · 23 Oktober 2019, 15:42:41

...wenn jemand ein funktionierendes Device hat und hier ein RAW einstellt, bastel ich gerne ein attrTemplate draus und packe den Code für's Wiederfinden ins Wiki (tendenziell zu den Praxisbeispielen, samt link im template...)

krikan · 23 Oktober 2019, 19:08:04

Rudi, das "Dann warten wir mal ab..." war nicht als Aufforderung an Dich gedacht, aber ich nehme den Code dankend an.

Zitat von: rudolfkoenig am 23 Oktober 2019, 15:09:32
Zu meinem Verstaendnis: wann werden welche Bitmaps gesendet?

Bisherige Einschätzung:
Einmalig kommt "ruhende" Grundrißbitmap mit Angabe der No-Go-Areas, Sauger/Ladestationsposition,...
Nach Start des Saugvorgangs wird jede Sekunde(!) die Grundrißbitmap wieder übertragen mit der geänderten Saugerposition (und Fahrweg?).
Habe mal einen Screenshot aus dem Valetudo-Frontend nach Start des Saugvorgangs als Beispiel angehängt; No-Go-Areas sind rot, Rest ist hoffentlich selbsterklärend. Am Ende des Saugvorgangs hat man in Valetudo eine Bitmap mit dem kompletten Fahrweg.

Zitat von: Beta-User am 23 Oktober 2019, 15:42:41
...wenn jemand ein funktionierendes Device hat und hier ein RAW einstellt, bastel ich gerne ein attrTemplate draus und packe den Code für's Wiederfinden ins Wiki (tendenziell zu den Praxisbeispielen, samt link im template...)

Liefere etwas, wenn ich mehr Klarheit habe. Das dauert noch. Kämpfe noch mit vielen Dingen.

Blöd ist unter anderem, dass nach Neustarts von MQTT auf dem Sauger ein neues MQTT2-DEVICE für den Sauger in FHEM per autocreate angelegt wird. Habe jetzt neben dem derzeit aktuellen MQTT2_mqttjs_5618b3f3, 2 alte und tote Devices (MQTT2_mqttjs_b3bf0259, MQTT2_mqttjs_fd62c953). Wie ich das in Valetudo anpassen kann, ist mir unklar. Oder gibt es dazu einen Weg über FHEM?

Gruß, Christian

rudolfkoenig · 23 Oktober 2019, 20:05:18

ZitatHabe mal einen Screenshot aus dem Valetudo-Frontend nach Start des Saugvorgangs als Beispiel angehängt; No-Go-Areas sind rot, Rest ist hoffentlich selbsterklärend. Am Ende des Saugvorgangs hat man in Valetudo eine Bitmap mit dem kompletten Fahrweg.

Ich habe in der Funktion nur den Grundriss implementiert, da ich die Koordinaten der anderen Werte nicht verstehe.

ZitatOder gibt es dazu einen Weg über FHEM?

Ja, in MQTT2_DEVICE readingsList kein clientId: spezifizieren, also nur topic:message als regexp.
Und entweder autocreate in MQTT2_SERVER auf no setzen, oder nach und nach alle topics in die richtige MQTT2_DEVICE Instanz migrieren.
Besser waere es valetudo beizubringen, einen festen Clientid zu verwenden.

ZitatNach Start des Saugvorgangs wird jede Sekunde(!) die Grundrißbitmap wieder übertragen mit der geänderten Saugerposition (und Fahrweg?).

Das duerfte ein rpi1 ueberfordern.

Beta-User · 23 Oktober 2019, 20:07:48

...etwas zu spät...

Das Ding scheint eine random-CID zu verwenden, das machen scheinbar einige Projekte auf pharo (?) -Basis so, kann man vermutlich irgendwo beim Compilieren der Firmware verhindern.
Kannst ja mal versuchen, die CID-Präfixe aus der readingList eines Eintrags zu entfernen und die anderen zu löschen.

rudolfkoenig · 23 Oktober 2019, 20:22:21

ZitatDas Ding scheint eine random-CID zu verwenden, das machen scheinbar einige Projekte auf pharo (?) -Basis so, kann man vermutlich irgendwo beim Compilieren der Firmware verhindern.

Ich habe jetzt dem MQTT2_SERVER ein clientId Attribut spendiert (analog zu MQTT2_CLIENT), was aber die autocreate Faehigkeiten auf die des MQTT2_CLIENTs reduziert.

Beta-User · 23 Oktober 2019, 20:27:19

...ist vermutlich einfacher, dann steht es in der commandref. Schade nur, dass die Leute voraussichtlich schnell vergessen haben werden, dass man das nach Anlegen der "Problemfälle" besser wieder ausschalten sollte...

rudolfkoenig · 23 Oktober 2019, 20:54:03

Die Problemfaelle muss man "frisieren" (d.h. readingList ohne clientid anlegen), sonst gibt es nach dem Ausschalten des Attributes wieder Chaos.

krikan · 24 Oktober 2019, 11:28:27

Zitat von: rudolfkoenig am 23 Oktober 2019, 20:05:18
Ich habe in der Funktion nur den Grundriss implementiert, da ich die Koordinaten der anderen Werte nicht verstehe.

Verständlich. Das Grundrissthema/Grafik werde ich selbst nicht weiterverfolgen, da ich so etwas in FHEM eigentlich nicht brauche. Evtl. findet sich jemand, der es weiter optimiert.
Störend ist mMn die enorme Sendefrequenz der "großen" MQTT-Nachrichten.

ZitatJa, in MQTT2_DEVICE readingsList kein clientId: spezifizieren, also nur topic:message als regexp.
Und entweder autocreate in MQTT2_SERVER auf no setzen, oder nach und nach alle topics in die richtige MQTT2_DEVICE Instanz migrieren.
Besser waere es valetudo beizubringen, einen festen Clientid zu verwenden.

Danke für den Hinweis zur Anpassung in FHEM.
Lösung in valetudo habe ich bisher nicht gefunden. Vielleicht kennt sich jemand anderes besser aus und kann aus den x .js-Dateien die passende Stelle herauslesen.

Beta-User · 24 Oktober 2019, 12:12:31

Gibt es auf dem Robbi eine Datei "/mnt/data/valetudo/config.json"?

Eigentlich hätte ich angenommen, dass das, was dort als identifier genannt wird, auch verwendet wird bzw. der default "roborock".

In dem Zusammenhang habe ich aber was interessantes gefunden: https://github.com/eclipse/paho.mqtt.python/issues/209#issuecomment-334481970. Da heißt es:

Zitat

paho will still try an empty client_id by default with MQTT 3.1.1.
but if the connect fail with rejected identifier (and client_id is empty), an random one is generated.

@Rudi: eventuell liegt das mit den "random" CID's auch daran, dass MQTT2_SERVER unbedingt eine ClientID haben will? (Wir hatten das Thema schon mit dem Octoprint, deswegen kam ich auf paho).
Eventuell wäre es ein (eventuell ebenfalls nicht unproblematischer) workaround, bei leerer ClientID-Angabe die IP-Adresse zu verwenden, von der die Anfrage kommt? (Ich habe das nicht im Code geprüft usw., weiß also nicht, ob das ein zielführender Vorschlag ist...!).

krikan · 24 Oktober 2019, 12:35:59

Zitat von: Beta-User am 24 Oktober 2019, 12:12:31
Gibt es auf dem Robbi eine Datei "/mnt/data/valetudo/config.json"?

Eigentlich hätte ich angenommen, dass das, was dort als identifier genannt wird, auch verwendet wird bzw. der default "roborock".

Ja, die gibt es, darin taucht die ClientId aber nicht auf und darum versuche ich bisher ergebnislos aus den x .js-Dateien zu ermitteln, woher die Client-Id kommt. Der MQTT-Abschnitt sieht übrigens so aus:

Code Auswählen

  "mqtt": {
    "enabled": true,
    "identifier": "rockrobo",
    "topicPrefix": "valetudo",
    "autoconfPrefix": "fhem",
    "broker_url": "mqtt://raspberrypi",
    "provideMapData": true,
    "caPath": ""
  },

Beta-User · 24 Oktober 2019, 12:55:03

Hmmm, ich kenn' mich ja mit Java auch nicht aus...

Das Random-Ding kenne ich noch von Octoprint (Diskussion hier), und auch von zigbee2mqtt. Beides scheint paho-basiert zu sein, und beides mal war das Schüsselwort "client_id". Vermutlich steht irgendwo im code von paho die Lösung und wir suchen an der falschen Stelle?

Vielleicht magst du einen Versuch mit einem zusätzlichen Element dieses Namens in der Liste in dem .json-file wagen?

krikan · 25 Oktober 2019, 07:48:32

Zitat von: Beta-User am 24 Oktober 2019, 12:55:03
Vielleicht magst du einen Versuch mit einem zusätzlichen Element dieses Namens in der Liste in dem .json-file wagen?

Hat leider keine Auswirkung/Erfolg.

Nach meiner mehr von Raten denn von Wissen getragenen Code/Repo-Analyse von Valetudo (bei besserer Kenntnis bitte berichtigen), komme ich zum gleichen Ergebnis:
Valetudo nutzt für mqtt: https://www.npmjs.com/package/mqtt/v/2.18.8

MQTT-Verbindung wird durch Valetudo in der function MqttClient.prototype.connect (https://github.com/Hypfer/Valetudo/blob/0.4.0/lib/MqttClient.js#L144) und dort speziell mit mqtt.connect (https://github.com/Hypfer/Valetudo/blob/0.4.0/lib/MqttClient.js#L150) aufgebaut.

Die per mqtt.connect übergebenen "options" werden in https://github.com/Hypfer/Valetudo/blob/0.4.0/lib/MqttClient.js#L150 ff. festgelegt. Die Konstante "options" wird in mit einem "leeren" Objekt initialiisiert "const options = {};" und anschließend nur noch die Eigenschaft "options.ca" vor dem Aufruf von mqtt.connect festgelegt. Alle anderen möglichen options von mqtt.connect (https://www.npmjs.com/package/mqtt/v/2.18.8#connect) werden also nicht übergeben und mit default-Werten beim Verbindungsaufbau angenommen. Festlegungen von clientId durch Valetudo, die als options bei mqtt.connect übergeben werden können, sind nach meiner Interpretation nur durch Code-Änderungen möglich. (nochmals: Bitte korrigiert mich gegebenenfalls.)

Als Standard vergibt mqtt eine zufallsbasierte clientId nach dem Schema

Code Auswählen

'mqttjs_' + Math.random().toString(16).substr(2, 8)
Das habe ich hier auch beobachtet. Diese clientId ändert sich demnach spätestens beim Client-Neustart immer wieder.

Allgemeiner zum MQTT-Protokoll:

Zitateventuell liegt das mit den "random" CID's auch daran, dass MQTT2_SERVER unbedingt eine ClientID haben will?

Nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349767 gilt doch der Grundsatz, dass die clientId existieren muss. Eine fehlende clientId "kann" der Server akzeptieren; muss er aber nicht. Da die clientId letztlich doch zur Identifizierung des einen, speziellen Gerätes verwendet wird, verstehe ich schon nicht, warum überhaupt "ohne clientId" erlaubt ist: Wie unterscheidet man verschiedene Geräte? Die Vergabe einer zufallsbasierten clientId ohne Speicherung, die einen Client-Neustart überlebt, ist für mich genauso unverständlich; letztlich kann man dann auch keine vergeben. Wie soll denn dann die Identifizierung mehrer (Valetudo-)Clients erfolgen? Nur durch Anpassung von bspw. "identifier": "rockrobo", "topicPrefix": "valetudo"? Was soll die clientId dann?

Das mqtt.js-Package wird doch häufig verwendet. Tritt das hier beobachetet Problem(?) auch bei anderen darauf basierenden Clients auf. Und über den "Tellerrand geschaut": Wie lösen andere MQTT-Server das Problem mit den clientIds.

Ach so, "gute" Quellen als Link zu meinen ? nehme ich gerne an. Bisher habe ich noch nicht herausgefunden, wo zusätzlich Erläuterungen zu MQTT halbwegs verlässlich zu finden sind.

edit: Verstümmelte Url-Links ausgebaut. Autokorrektur

rudolfkoenig · 25 Oktober 2019, 09:09:14

Die clientId kriegt nur der MQTT-Server, sie wird nicht an den anderen Clients weitergegeben.
Soweit ich weiss, ist "unclean Session" die einzige beabsichtigte Verwendug der clientId: wenn der Server ein unclean Session akzeptiert, dann gelten die Subscriptions vom letzten Session.
MQTT2_SERVER akzeptiert nur clean Sessions.

Ich kann die Idee mit der IP bei leerer clientId implementieren, bin aber unsicher, ob das nicht mehr Probleme verursacht, brauche also eine weitere Stimme

Otto123 · 25 Oktober 2019, 09:35:20

Ich gebe mal mein "gelerntes" der letzten Tage wieder:
mosquitto verwendet, wenn keine CID angegeben wird, den Namen + die Prozess ID (Defaults to mosquitto_sub_ appended with the process id.)
cloudmqtt lässt bei der Anmeldung jede CID nur einmal zu.
Die Tools die ich probiert habe (mqttbox, MyMQTT, Chrome Plugins) verfahren so wie mqttbox schreibt: It should be unique per client for given broker. The broker uses it for identifying the client and the current state of the client. It is auto generated by default.

Also die CID ist scheinbar wirklich wurscht, außer bei autocreate vom MQTT2_SERVER/CLIENT

Jeder Client (egal mit welcher CID) kann bei Standardeinstellung des Servers in einen (den gleichen) Topic publishen.
Also man muss auf den Topic aufpassen beim publishen. Namen die in den Topic einfließen müssen Unikat sein! Insofern ist mir die Standardnamensgebung des Topic bei Tasmota völlig unklar, alle anderen Namen sind Unikat nur der Topic nicht

Ist jetzt sicher für die Anwesenden nichts neues, ich wollte nur Christian bei seinen Erkenntnissen bestätigen

Beta-User · 25 Oktober 2019, 09:56:48

(In Teilen überschnitten mit Otto's Hinweisen, die aber interessanterweise mir unbekannte Tools referenzieren; zumindest das ist (für mich) was neues...)

Zitat von: krikan am 25 Oktober 2019, 07:48:32Allgemeiner zum MQTT-Protokoll:Nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349767 gilt doch der Grundsatz, dass die clientId existieren muss. Eine fehlende clientId "kann" der Server akzeptieren; muss er aber nicht. Da die clientId letztlich doch zur Identifizierung des einen, speziellen Gerätes verwendet wird, verstehe ich schon nicht, warum überhaupt "ohne clientId" erlaubt ist: Wie unterscheidet man verschiedene Geräte? Die Vergabe einer zufallsbasierten clientId ohne Speicherung, die einen Client-Neustart überlebt, ist für mich genauso unverständlich; letztlich kann man dann auch keine vergeben. Wie soll denn dann die Identifizierung mehrer (Valetudo-)Clients erfolgen? Nur durch Anpassung von bspw. "identifier": "rockrobo", "topicPrefix": "valetudo"? Was soll die clientId dann?

Das mqtt.js-Package wird doch häufig verwendet. Tritt das hier beobachetet Problem(?) auch bei anderen darauf basierenden Clients auf. Und über den "Tellerrand geschaut": Wie lösen andere MQTT-Server das Problem mit den clientIds.

Dass das Problem mit den Random-clientId's besteht, hatte ich ja bereits geschrieben, bisher waren das noch zigbee2mqtt und Octoprint.

Dass da eine Random-Angabe verwendet wird, hat wohl damit zu tun, dass nach dem, was du schreibts, eben der Broker die Angabe verlangen kann (dann wird dem entsprochen), aber nicht muß. Da der beliebte mosquitto zu den Vertretern der "ist mir egal"-Fraktion zu gehören scheint, ist das Problem für viele schon gar nicht existent (mir war vor der "MQTT2-Zeit" auch nicht klar, dass da überhaupt was ist, allerdings ohne mich je mit den Grundlagendokumenten dazu auseinandergesetzt zu haben...).

Generelle Feststellung also: In der MQTT-Welt ist der Topic-Tree nach meinem Empfinden das eigentlich wesentliche, und um den zu manipulieren, stellen praktisch alle Frameworks/firmwares (soweit ich die bisher kennengelernt habe, was nicht zu viel Erfahrung ist) Mittel bereit. Das ist also mMn. das eigentliche Unterscheidungsmerkmal, nicht die clientId.
Dazu kommt: Es gibt (zumindest mit mosquitto) auch die Möglichkeit, Server zu brücken, also Daten miteinander auszutauschen. Spätestens dann geht die Quellenangabe aus der clientID verloren, und ein Stück weit auch die Unterscheidung zwischen Server und Client.

Ob allerdings mit der Verwendung der IP (die ja meistens einigermaßen statisch ist) ein Sicherheitsrisiko verbunden ist,entzieht sich meiner Kenntnis, tendiere aber dazu, das zu verneinen, denn letztlich entscheidet ja der Client, unter welcher clientID er sich zu erkennen geben will...

Zu dem Tasmota-OT: dass da im default "sonoff" verwendet wird, ist wirklich unglücklich und vermutlich nur aus der Historie zu erklären... Der Hinweis auf der Webseite des Projekts, dass man den ändern sollte, ist da kein wirklicher Ersatz für eine Änderung an der Stelle (warum nicht die Chip-ID verwenden, wie an anderer Stelle auch?).

herrmannj · 25 Oktober 2019, 12:09:08

Das Verhalten dass verschiedene clients unter der gleichen topic publishen dürfen finde ich gut und "Erhaltenswert"

Beta-User · 25 Oktober 2019, 12:38:24

Zitat von: herrmannj am 25 Oktober 2019, 12:09:08
Das Verhalten dass verschiedene clients unter der gleichen topic publishen dürfen finde ich gut und "Erhaltenswert"

MMn würde sich daran auch durch die "IP-Lösung" nichts ändern, wenn
- entweder wenigstens einer der Clients eine clientID bereitstellt oder
- die IP-Adresse unterschiedlich ist.

Grundsätzlich würde ich aber jedem Anwender empfehlen, die Topic-Struktur so zu gestalten, dass Verwechslungen ausgeschlossen werden. Andernfalls ist zu befürchten, dass wir sonst immer mal wieder Anwender haben werden, die den Unterschied nicht kennen und dann beim "Rückweg" in der setList nicht sauber operieren (hatten wir das nicht auch schon bei einem Tasmota-Anwender, der immer 4 Geräte gleichzeitig an- bzw. ausgeschaltet hatte?). Auch die attrTemplates ignorieren (bisher und weitgehend) die CID, und es wäre zumindest ein gewisser Aufwand, das zu "korrigieren"...
Apropos "Korrektur": Das würde dann auch dazu führen, dass man nicht mehr so einfach das IO wechseln könnte (SERVER zu CLIENT und anders rum, CLIENT liefert btw. sowieso prinzipbedingt nichts "brauchbares").

rudolfkoenig · 25 Oktober 2019, 13:43:15

Das Wissen ueber die ClientId ermoeglicht topics automatisch einzelnen Geraeten zuzuordnen, und da mein Ziel mit MQTT2_SERVER die MQTT-Integration in FHEM zu vereinfachen war, habe ich das gerne genutzt.
Ohne Clientid muss man die Instanzen entweder komplett manuell oder mit einer manuell gepflegten "Datenbank" (siehe die Bridge-Devices) anlegen.

Ein Wechsel vom MQTT2_SERVER zu MQTT2_CLIENT ist aufwendig, weil autocreate die ClientIDs in den readingList Attributen verewigt, und das muss man entfernen. Und hoffen, dass nicht mehrere Geraete die gleichen topics befuellen. Der Wechsel in die andere Richtung (MQTT2_CLIENT => MQTT2_SERVER) sollte problemlos sein.

Beta-User · 25 Oktober 2019, 14:31:05

Der Mechanismus an sich ist top!

Den Vorteil sehe ich vor allem auch darin, dass über die CID jeweils (auch später noch) das "richtige" Gerät ermittelt werden kann. Bitte das ganze nicht als Wunsch mißinterpretieren, das auszubauen, sondern +1 für erhalten...

Zu dem Wechseln von CLIENT=>SERVER aber noch: Wird nicht auch bei CLIENT eine CID übergeben (eben die des CLIENT) und dann in der readingList verewigt?
Ich hatte schon länger keinen CLIENT mehr in Betrieb, kann also sein, dass das zwischenzeitlich mal geändert wurde, aber ich habe das noch anders im Kopf (? ist evtl. anders, wenn das durch eine bridgeRegexp durch ist...?). Bei CLIENT macht das "Merken" der CID jedenfalls meistens wenig Sinn (mal abgesehen von dem etwas speziellen Fall, dass man mehrere Server hat, die jeweils einen eigenen CLIENT haben). Wenn das also noch so wäre, wäre der Wechsel auch in diese Richtung mit hohem Aufwand verbunden...

Aber abgesehen davon, ist die erste Frage doch: Schickt das js-Framework immer _gleich_ eine random-clientID oder wird es erst ohne cientID versucht, und dann erst nachgelegt (wie das der von mir neulich zitierte Beitrag schildert) ? Das ergibt sich aus den von krikan verlinkten Stellen für mich nicht so recht. Sieht man dazu ggf. was im log des SERVERS?

Kommt immer gleich eine Random-clientID, ist es schwierig (bzw.: man könnte das Muster erkennen), ansonsten müßte man "nur" den "unbenannten" Client akzeptieren und selbst eine CID vergeben.

Ansonsten vielleicht noch eine Ergänzung zur Frage, wie andere Projekte das lösen mit der userseitigen Vergabe der clientID: Unter https://github.com/OctoPrint/OctoPrint-MQTT/pull/60/commits/6e686f5c621a0fdf43ebc742a7630f1906de5687 scheinen die (überschaubaren) Änderungen zu stehen, die bei OctoPrint ausreichend waren, um das Problem "an der Wurzel" aus der Welt zu schaffen. Vielleicht kann damit jemand eine Lösung für Valetudo basteln...

krikan · 25 Oktober 2019, 18:03:17

Danke für Euren Input; muss jetzt erst einmal gedanklich sortieren.
Und ich möchte erst mal in FHEM gar nichts ändern, sondern MQTT halbwegs verstehen, bevor ich mir eine Meinung zu Änderungen in FHEM erlauben kann.

Zitat von: Beta-User am 25 Oktober 2019, 14:31:05
Aber abgesehen davon, ist die erste Frage doch: Schickt das js-Framework immer _gleich_ eine random-clientID oder wird es erst ohne cientID versucht, und dann erst nachgelegt (wie das der von mir neulich zitierte Beitrag schildert) ? Das ergibt sich aus den von krikan verlinkten Stellen für mich nicht so recht. Sieht man dazu ggf. was im log des SERVERS?

Interpretiere mqtt.js-API-doku so, dass sofort eine Zufalls-clientId verwendet wird, wenn keine vorgegebene clientId als "options" bei mqtt.connect übergeben wird. Das sehe ich auch so im verbose-5 Log bestätigt. Das ist eine erstmalige CONNECT-Nachricht des Clients an den FHEM-Server:

Code Auswählen

2019.10.22 12:40:19.738 4: Connection accepted from fhemMqtt_192.168.188.46_38902
2019.10.22 12:40:19.780 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_fd62c953
2019.10.22 12:40:19.781 4:   fhemMqtt_192.168.188.46_38902 mqttjs_fd62c953 CONNECT V:4 keepAlive:60
2019.10.22 12:40:19.781 5: out: CONNACK:  (2)(0)(0)

Die Codeänderung für Valitudo für die Vorgabe einer clientId dürfte, wenn meine obige Valetudo-Analyse stimmt, sicherlich relativ einfach sein. Habe aber keine Energie das zu testen/make zu starten. $:-\$ Die Vorgehensweise von MQTT/mqtt.js bei der clientId wird sicherlich einen Grund haben.

Beta-User · 25 Oktober 2019, 19:01:00

Hmm, ok, bin auch der Meinung, dass man in den FHEM-Modulen nichts ändern sollte.

Was "wir" liefern könnten, wäre ein attrTemplate, das die CID-Angaben aus der readingList wirft und die Steuerungs- und Abfragebefehle bereitstellt

. Aber das ist unter diesem Thread-Titel wohl "falsch"

. (Ich würde eine RAW-Definition von dem Ding benötigen und evtl. einen schnellen Link zu den Befehlen, die via MQTT akzeptiert werden, dann kann ich beizeiten einen ersten Wurf liefern...).

Bei Gelegenheit werde ich wohl auf jeden Fall die bridgeRegexp im allgemeinen "Client"-template anpassen/erweitern, dass die "identifier"-Angabe (typisch: "rockrobo") als CID verwendet wird, was auch immer dann in der .json verwendet wird...