Neueste Beiträge

#1
Sonstige Systeme / Aw: Xiaomi WiFi Devices Modul ...
Letzter Beitrag von Meesus - 08 Juni 2026, 22:46:15
Hallo in die Runde,
ich habe mir einen neuen Xiaomi Robot Vacuum 5 pro (xiaomi.vacuum.ov21gl) gekauft. Jetzt weiss ich ja das dieses Modul nicht mehr weiterentwickelt wird.
Den Token habe ich bereits und kann auch mit "get" über "device_Info" 4 Werte abfragen. Das war es dann auch schon.

Gibt es trotzdem eine Möglichkeit ein neues Model damit rein zupacken? Ich benötige eigentlich nur die Raumsteuerung, damit ich den Sauger in einen bestimmten Raum über Alexa schicken kann. Oder kann man mit Einzelbefehle über die Console etwas erreichen?

Gruß Micha
define vacuum XiaomiDevice 192.168.0.146 573870634c64554e7042376a35xxxxxx
attr vacuum room Test
attr vacuum subType VacuumCleaner
attr vacuum verbose 1
#  CFGFN     
#  DEF        192.168.0.146 573870634c64554e7042376a35xxxxxx
#  FD        138
#  FUUID      6a25c5c7-f33f-8dc8-d6cf-95bbe4bd706088e3
#  NAME      vacuum
#  NR        1815
#  STATE      ???
#  TYPE      XiaomiDevice
#  eventCount 567
#  hardware  Linux
#  mac        C8:26:E2:0D:DC:39
#  model      xiaomi.vacuum.ov21gl
#  token      573870634c64554e7042376a35xxxxxx
#  READINGS:
#    2026-06-08 22:22:35  device_firmware 4.5.8_0183
#    2026-06-08 22:22:35  device_uptime  79.23
#    2026-06-08 22:22:35  error          none
#    2026-06-08 22:22:35  wifi_rssi      -50
#  helper:
#    ConnectionState connected
#    crypt      AES
#    delay      60
#    dev        45ef
#    id        ee85
#    ip        192.168.0.146
#    last_read  1780950155
#    packetid  554
#    port      54321
#    rc_seq    1
#    sequence  1780664933
#    token      573870634c64554e7042376a35xxxxxxx
#    packet:
#      550        get_status
#      551        get_status
#      552        device_info
#      553        get_status
#
setstate vacuum 2026-06-08 22:22:35 device_firmware 4.5.8_0183
setstate vacuum 2026-06-08 22:22:35 device_uptime 79.23
setstate vacuum 2026-06-08 22:22:35 error none
setstate vacuum 2026-06-08 22:22:35 wifi_rssi -50

2026.06.08 21:01:56 4: vacuum: parse id 515 / get_clean_summary
2026.06.08 21:01:56 4: vacuum: msg ref is
2026.06.08 21:01:56 5: vacuum < 213100700000000045efee850004474102da83af110e12a898233994327d4f0ea6b58456ebd197b92a4717a831bf706da13e72ca0aa5d1ca836bf8d6f91032e424e0cb354a615bee35dbc1f9a6572aea51c7e91ef63b417b77fe0bbd09ad24c67628e9331c8480330ca88a7d9820ba5c (112)
2026.06.08 21:01:56 5: vacuum: decrypted
{"id":516,"error":{"code":-9999,"message":"user ack timeout"},"exe_time":4007}
2026.06.08 21:01:56 5: vacuum: parse id 516
$VAR1 = {
          'error' => {
                       'code' => -9999,
                       'message' => 'useracktimeout'
                     },
          'id' => 516,
          'exe_time' => 4007
        };
#2
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von Sidey - 08 Juni 2026, 22:18:06
Zitat von: FlatTV am 08 Juni 2026, 21:15:53Falls das irrelevant ist, ignoriert diesen Post einfach.

Ist doch gut zu wissen, dass es scheinbar nicht jeden bisher betroffen hat.
Das kann sich ja auch ändern.

Grüße Sidey
#3
Sonstige Systeme / Aw: Netatmo Modul - 38_netatmo...
Letzter Beitrag von flydd - 08 Juni 2026, 21:32:00
Ich habe nochmal einen kleinen Patch erstellt. homecoachsdata wird jetzt wie homecoachlist an netatmo_parseHomecoachList übergeben. Das sollte das Problem lösen.
#4
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von FlatTV - 08 Juni 2026, 21:15:53
Also erstmal Danke an den Maintainer Michael, dass er sich um das Modul kümmert.

Ich lese hier fleißig mit, meine Installationen laufen aber beide noch!?
Einmal der docker alexa-cookie-service und auch der pi mit Trixie.

Falls das irrelevant ist, ignoriert diesen Post einfach.
#5
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von Sidey - 08 Juni 2026, 19:56:42
Hi,

meine 5ct mal zu dem Problem:


Also ich habe ja vor einigen Wochen das alexa-cookie-service container image erstellt. Das stellte eine REST api für alexa-cookie zur Verfügung.
Es läuft also die gleiche Version der alexa-cookie Bibliothek. Die node Version könnte sich durchaus von eurer unterscheiden.

Ich habe den Login Prozess vor 6 Stunden noch mal neu durchgeführt und mich darüber registriert.
Da gibt es kein Problem. Der Intervall für das Refresh token habe ich auf 16 Stunden belassen. Läuft jetzt schon mehrere Stunden ohne refresh.


Grüße Sidey
#6
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von michael.winkler - 08 Juni 2026, 19:00:11
Bitte geduldet Euch noch etwas. Ich bin an der Sache dran. Aktuell sieht es so aus, dass das Problem nicht vom Modul kommt, sondern von der NPM Komponente. Ich bin mit dem Entwickler dran. Sobald ich was weiß melde ich mich wieder.
#7
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von michael.winkler - 08 Juni 2026, 18:59:57
Bitte geduldet Euch noch etwas. Ich bin an der Sache dran. Aktuell sieht es so aus, dass das Problem nicht vom Modul kommt, sondern von der NPM Komponente. Ich bin mit dem Entwickler dran. Sobald ich was weiß melde ich mich wieder.
#8
MAX / Aw: Neue Beta Test Runde für a...
Letzter Beitrag von don.redhorse - 08 Juni 2026, 18:55:06
Hallo zusammen.

Erst einmal vielen Dank an Wzut, dass er sich dem Modul zugewendet hat.
Am Wochenende habe ich meine MAX! Installation ebenfalls auf die Beta hochgezogen.
verbaut sind ein MaxLAN, der zum CUNo geflasht wurde "V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)"
8 Thermostate sind verbaut und 4 Shutter Contacts.
Ein DOIF ist eingerichtet und die Temperaturen zu pollen, dass tut. Die Patches sind drin, abgesehen vom Bug mit Keep und dem Boost.
Die Heizperiode ist zwar durch, aber gerade in dieser Zeit ist es ja doch ein wenig doof gewesen die Thermostate andauernd verfahren zu müssen um mit dem Scanner die Werte auslesen zu können, bzw. das Senden zu erzwingen.
Die Wochenprogramme habe ich jetzt noch nicht getestet, letztes Jahr hatte ich die eh alle gekickt und die Wunschtemperaturen per Script und Cronjob gesteuert. Mit dem Scanner und den Wochenprogrammen gab es ab und an Ärger, deswegen diese Lösung. Denke mal das kann ich bis zum Herbst hin wieder umstellen, auf reguläre Wochenprogramme.
Ein Thermostat ist diesen Winter eines mechanischen Todes gestorben, da ist so jemand gegengeballert, dass das Gehäuse gerissen war. Deswegen habe ich auch zwei Homematic Thermostate verbaut. Da bin ich mir noch nicht so ganz sicher was mir besser gefällt, die MAX! waren eigentlich immer einfacher zu beherrschen...
Mal gucken was die Zukunft bringt.
#9
Fehlerberichte / nanoCUL Parse_MN, Error! id 11...
Letzter Beitrag von TobSch - 08 Juni 2026, 16:59:03
Hallo zusammen,

seit folgender Änderung https://github.com/mhop/fhem-mirror/commit/cb7fd4982b0cf43c23ae98af51e3b853e4874b37 in SD_Protocols.pm bekomme ich Fehlermeldungen beim Verarbeiten der Sensordaten meiner BRESSER_7-in-1_Wetterstation:

2026.06.08 15:58:09 4: nanoCUL_868MHz: Read, msg: MN;D=372FB2BEBC8A18AAAAAAAAAAAAAA8B8ACEAAAA9FAAAA;R=58;A=4;
2026.06.08 15:58:09 4: nanoCUL_868MHz: Parse_MN, Error! id 117 msg=372FB2BEBC8A18AAAAAAAAAAAAAA8B8ACEAAAA9FAAAA, message is to short




Mit der SD_Protocols.pm 2.07 (anstatt 2.09) läuft es (die dazu passende SD_ProtocolData.pm vorausgesetzt):

Internals:
   CODE       SD_WS_117
   DEF        SD_WS_117
   FUUID      64f43401-f33f-49f8-8899-cb8c3ca745098f0e
   FVERSION   14_SD_WS.pm:v1.1.7-s30748/2026-01-17
   LASTInputDev nanoCUL_868MHz
   MSGCNT     190
   NAME       SD_WS_117
   NR         277
   STATE      T: 21.3 H: 64 W: 0 R: 0 B: 0.103
   TYPE       SD_WS
   bitMSG     01001010101100000001100000010100000101100010000010110010000000000000000000000000000000000000000000000000000000000010000100110000011001000000000000000001000000110000000000000000
   eventCount 42
   lastMSG    4AB018141620B2000000000000002130640001030000
   lastReceive 1780930327.39694
   nanoCUL_868MHz_DMSG W117#4AB018141620B2000000000000002130640001030000
   nanoCUL_868MHz_FREQAFC 6
   nanoCUL_868MHz_MSGCNT 190
   nanoCUL_868MHz_Protocol_ID 117
   nanoCUL_868MHz_RAWMSG MN;D=E01AB2BEBC8A18AAAAAAAAAAAAAA8B9ACEAAABA9AAAA;R=58;A=4;
   nanoCUL_868MHz_RSSI -45
   nanoCUL_868MHz_TIME 2026-06-08 16:52:07
   READINGS:
     2026-01-27 16:11:37   batteryChanged  1
     2026-06-08 16:52:07   batteryState    ok
     2026-06-08 16:52:07   brightness      0.103
     2026-06-08 16:52:07   humidity        64
     2026-06-08 16:10:09   model           Bresser 7-in-1 outdoor sensor
     2026-06-08 16:52:07   rain            0
:
:
:


#10
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von duu75 - 08 Juni 2026, 16:24:05
Kurzes Update zu meinem "not connected" Problem.

Jetzt geht es alles wieder.
Habe aber den ganzen Alexa2 Cookie npm Kram komplett löschen müssen und auch alle FHEM Device Definitionen!
Nach komplett Ubuntu Neustart dann from Scratch alles neu installiert und definiert, npm_login new usw.
Dann waren die Echos wieder sauber ansprechbar und auch wirklich ONLINE.

Refresh Intervall auch erstmal auf 60 gedreht und beobachte weiter was passiert und parallel in ioB.


Update:
Ich breche zusammen, es sind schon wieder alle echodevices angeblich connected, aber alle commands laufen auf not connected aborting hinaus.
Und ich kriege es noch nicht mal wieder mit der gleichen Prozedur von vorhin wieder zum laufen.
Ich gebe vorerst auf.