Problem mit Unterputzaktor

Begonnen von HHFHEM, 14 September 2016, 17:12:01

Vorheriges Thema - Nächstes Thema

HHFHEM

Hallo,
Versuch ein SW1PBU- FM zu pairen scheitert. Er wird zwar von Fhem erkannt, zeigt die Änderung beim Drücken des Schalters an, lässt sich aber von Fhem nicht steuern. Habe nun versucht mit einem PB-2-WM 55 zu peeren.
Danach erhalte ich die Meldung des Channels : chn 01  expect AES bzw. chn 01  NeedsBurst. Nutze kein AES.
Für Hilfe im Voraus besten Dank.

gloob

Wenn er den Status anzeigt aber nicht von FHEM aus schaltet, dann ist er nicht richtig gepairt. Zeig doch mal ein List vom device
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

HHFHEM

Genau das ist mein Problem: Pairen mit PairForSec erzeugt lediglich Unknown Code...., Pairen mit Serial funktioniert "teilweise" mit beschriebenem Problem.

LuckyDay

ZitatPairForSec

den Befehl gibt es so auch nicht ;)


HHFHEM

#4
die Schreibweise wurde von mir gekürzt. Den Befehl hm.....kenne ich natürlich. Habe das Problem mit einem Hinweis im Forum (Otto sei Dank) lösen können. Wiederholtes Anlernen mit hmPairSerial hat mein Problem gelöst. Nun habe ich im Log den Eintrag HM... has no type. Den Eintrag kannte ich so noch nicht. Welchen Type muss ich ergänzen?
mfg

Deudi

Zitat von: HHFHEM am 14 September 2016, 20:20:15
Welchen Type muss ich ergänzen?
Mach ein "shutdown restart" dann ist das wieder ok.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

Muschelpuster

Zitat von: HHFHEM am 14 September 2016, 20:20:15Wiederholtes Anlernen mit hmPairSerial hat mein Problem gelöst.
Bei mir das Gleiche. Mit einen UP-Aktor und einem 4-fach-Hutschienenaktor. Einach nach dem hmPaifForSec aus dem Gerät die Serial kopiert und nochmal ein hmPairSerial nachgeschoben.  Und schon ist alles gut. Das sollte man irgendwie im Wiki vermerken, nur fehlt mir gerade der Ansatz, wie das am Elegantesten zu lösen ist und ob mein Vorgehen von den Experten als exakt eingestuft wird.

gelöste Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Otto123

Hallo Niels,

das mit dem zweiten Pairen ist sicher meist eine Lösung, aber ich glaube mittlerweile die richtige Lösung ist irgenwie anders.
Ich habe bei einigen FHEM Installationen gemerkt, dass das getConfig, was eigentlich nach dem Pairen ausgelöst wird, nicht sauber abläuft. Oder gar nicht ausgelöst wird...
Ich wollte mich die nächsten Tage nochmal dran setzen und das mal etwas analysieren, ich hoffe ich werde da schlauer. Und ich wollte meine Erkenntnisse ins Wiki schreiben  8)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Muschelpuster

Hallo Otto,

Das GetConfig wurde bei mir bei beiden Geräten ausgelöst, jedoch blieb es mit einen 'Error Reading Register' hängen und der Status der Devices ging auf Missing ACK.

ergänzende Grüße
Niels
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Otto123

Moin  8)

Ja ich weiß, so habe ich das auch schon gesehen. Und dann macht man jede Menge Aktionen und irgendwann geht es dann - und man weiß eigentlich nicht warum es jetzt geht und am Anfang nicht funktioniert hat. Und man weiß dann nicht: war jetzt der Aktor oder FHEM oder man selbst das Problem?

Ich habe das Gefühl, als ob sich einer beim pairing selbst am eigenen Schopf aus dem Unbekannheitssumpf zieht und je nach Tagesform geht es oder es geht schief.

Ich will es jetzt mal verstehen und nach Fehlern gezielt suchen können  ;)

mit neugierigen Grüßen  ;D
Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Benni

Zitat von: Otto123 am 15 September 2016, 10:34:24
Und dann macht man jede Menge Aktionen und irgendwann geht es dann - und man weiß eigentlich nicht warum es jetzt geht und am Anfang nicht funktioniert hat. Und man weiß dann nicht: war jetzt der Aktor oder FHEM oder man selbst das Problem?

Stimmt! So läuft das bei mir meistens auch ab  ::)
Und wenn's dann endlich passt hat man meist nicht mehr die Muse zu schauen, wie's eigentlich ging. Fällt einem dann erst wieder ein wenn es mal wieder was neues zu pairen gibt ;D

martinp876

Pairen läuft so ab:
Fhem wird scharf geschaltet
Config am device wird ausgelöst
Fhem legt das device als Datensatz an wenn nicht vorhanden
Evtl. Anstehende Kommandos in der q werden in fhem geloescht
Fhem sendet das pairen
Fhem queued ein getconfig.

Ein Problem ist die nicht echtzeitfaehigkeit von fhem. Insbesondere das Anlegen des Datensatzes geht über fhem zentral. Dabei kann einiges passieren was unvorhersehbar Zeit kostet. Als Konsequenz kann es passieren, dass wir zu langsam sind und das device austimed. Dann geht nichts mehr, die Kommandos werden ignoriert.

Wenn man das 2. Mal pairt ist das device schon angelegt was deutlich Zeit spart. Daher kann dies schon besser gehen.
Sollte das Problem nach dem pairen und beim getconfig auftreten fehlt nur die Rückmeldung. Man kann hier ein clear msgevents und ein getconfig machen und sehen ob es klappt. Wenn das device gepairt war bekommt man die Antwort und alles ist gut.