Xiaomi WiFi Devices Modul (Vacuum/Airpurifier/Fan) - 72_XiaomiDevice (Support)

Begonnen von Markus M., 11 Juni 2017, 12:48:58

Vorheriges Thema - Nächstes Thema

ext23

Mhh das Java script ist ja sehr einfach, aber wenn ich schon sehe:
function copyFiles(source, destination) {
   const files = ['user_map0', 'last_map', 'PersistData_1.data', 'PersistData_2.data'];
...

diese user_map0 habe ich nicht beim Gen.1. Auf die Idee die zu kopieren bin ich auch schon bekommen aber irgendwie gibts die bei mir alle nicht. nur die last_map.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Zitat von: MadMax-FHEM am 22 Juli 2019, 16:06:45
Es sind teilweise auch andere Sensoren verbaut...

Wo steht das? Also das was wir alles geprüft haben, auch die Sensoren, ist alles identisch. Nur weil das Board ne andere Bauform hat ist das ja nicht gleich ein anderes Board. Hast du da ein Link zu wo das mal jemand beschrieben hat was da wirklich anders ist?

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

So also wie beschrieben scheint das wirklich zu klappen. Die last_map überschreiben mit einem backup und dann ein reboot machen (Was der Sauger ja eh jede Nacht macht) oder aber den player process killen und dann ist die alte Karte wieder da.

Ich werd also vor jedem Zone Cleanup die Datei zurückschreiben, den player killen und wenn der wieder da ist den zone cleanup starten. Da muss ich mir wohl mal ein bash script bauen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

MadMax-FHEM

Das mit den Sensoren hab ich irgendwo im Roboterforum oder sonstwo gelesen.

Zumindest der vordere Sensor ist anders bzw. hat der V2 dort 3 und der V1 nur 1...

Hab grad geschaut, hab ja beide...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

hoppel118

Hallo Leute,

wenn ich meine Smart-Fans mal vom Strom nehme und nicht in Betrieb habe, weil Akku leer, sehe ich Unmengen folgender Meldungen in meinem Logfile:

2019.08.03 22:09:28 3: DG_SZ_Ventilator: disconnecting
2019.08.03 22:09:28 2: DG_SZ_Ventilator: connecting
2019.08.03 22:09:28 3: DG_SZ_Ventilator: initialized
2019.08.03 22:10:20 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:15:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:20:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:25:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:30:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:35:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:40:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:45:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:50:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 22:55:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:00:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:05:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:10:20 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:15:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:20:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:25:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:30:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:35:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:40:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:45:23 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:47:20 3: DG_SZ_Ventilator: disconnecting
2019.08.03 23:47:20 2: DG_SZ_Ventilator: connecting
2019.08.03 23:47:20 3: DG_SZ_Ventilator: initialized
2019.08.03 23:48:12 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:53:15 3: DG_SZ_Ventilator: connection timeout
2019.08.03 23:58:15 3: DG_SZ_Ventilator: connection timeout


Da wird also alle 5 Minuten ein "connection timeout" ins Logfile geschrieben. Bisher habe ich das Verbose Level an diesen Devices nicht angepasst. Wenn ich verbose auf 2 setzen würde, würde ich nur noch alle paar Stunden die "connecting" Meldungen sehen. Irgendwie ist mir das aber auch noch zu viel "Müll" im Logfile. Wenn ich die Lüfter nun im Winter einmodden würde, müsste ich das verbose Level wohl auf 0 setzen, um wirklich gar keine Meldungen mehr zu sehen.

Wie geht ihr damit um oder was empfehlt ihr mir?

Danke und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Markus M.

verbose 2 wenn Disconnects vorauszusehen sind und im Winter einfach das disable Attribut setzen.
So mache ich das zumindest mit Ventilator und Luftbefeuchter.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

hoppel118

Alles klar, weiß ich Bescheid. Habe direkt mal verbose 2 bei meinen beiden Ventilatoren gesetzt.

Danke und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

ralf-ms

Hallo Markus,

hab bei mir den Xiaomi 1S im Einsatz:
es gibt einen neuen Status für 'state' im get_status (vacuum_states):
18: Targeted Clean

ausserdem kann "in_cleaning" auch > 1 sein.
Ich bekomme bei verbose=5 bei "get_state" folgende Info für einen targeted clean zurück:

$VAR1 = {
  'id' => 628,
  'result' => [
    {
      'battery' => 94,
      'clean_area' => 15852500,
      'clean_time' => 678,
      'dnd_enabled' => 0,
      'error_code' => 0,
      'events' => [],
      'fan_power' => 102,
      'in_cleaning' => 3,
      'in_fresh_state' => 0,
      'in_returning' => 0,
      'lab_status' => 1,
      'map_present' => 1,
      'map_status' => 3,
      'msg_seq' => 191,
      'msg_ver' => 1,
      'state' => 18
    }
  ]
};


Ich hab die Änderungen bei mir mal testweise gemacht, und es wird jetzt der richtige Status angezeigt.
Vllt kannst du das beizeiten noch einpflegen...

Danke!  :)

Markus M.

FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0


Dersch


Thyraz

Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Dersch

OK super, danke! Dann freue ich mich nun noch mehr auf die Lieferung :)

hoppel118

Jo, läuft astrein, mit aktuellster Firmware: 3.3.9_001886

Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

ucm73

Hi,
ich habe ein Problem mit dem Xiaomi Mijia Fan 1X. Er wird als dmaker.fan.p5 erkannt. Die Firmware ist 2.0.4. RSSI wird auch noch ausgelesen.
Das war es dann auch, jeglicher Befehl wird mit einem error "useracktimeout" quittiert.
Im log erscheint dann:
Zitat
019.08.18 16:56:41.736 5: Ventilator: decrypted
{"id":5,"error":{"code":-9999,"message":"user ack timeout"}}
2019.08.18 16:56:41.736 5: Ventilator: parse id 5
$VAR1 = {
          'error' => {
                       'code' => -9999,
                       'message' => 'useracktimeout'
                     },
          'id' => 5
        };

2019.08.18 16:56:41.736 4: Ventilator: parse id 5 / fan_data
2019.08.18 16:56:41.737 4: Ventilator: msg ref is

Liegt das am Modul oder an mir?