Neigungssensor meldet falschen Zustand

tndx · 16 Dezember 2016, 23:22:15

Hallo zusammen,

ich habe seit einiger Zeit einen Neigungssensor im Einsatz, habe ihn aber bis jetzt aber nicht wirklich beachtet sondern nur eingerichtet und (mehr oder weniger) mitlaufen lassen. Nun wollte ich dessen Zustand zur Visualisierung des Torzustands nutzen und habe ihn mir genauer angesehen und dabei festgestellt, dass da wohl noch einiges im Argen ist. Im Moment meldet er mir schlicht den falschen Zustand, also "open", obwohl das Tor definitiv zu ist. Auch ein auf- und zu machen des Tores hat dabei nichts bewirkt.

Hier ein list:

Code Auswählen

---

Hier ein Auszug aus der Logdatei:

Code Auswählen

---

tndx · 17 Dezember 2016, 21:31:48

Ich habe erst heute festgestelllt, dass die Foren-SW meinen Post beschnitten hatte, da es wohl eine Grenze bei der Textlänge gibt. Ich habe nun den Logausschnitt gekürzt und wollte noch den fehlenden Text nachliefern:

Mir ist natürlich aufgefallen, dass das Ding mittlerweile im Zustand "aesCommToDev: pending" hängt, aber zum einen lief es schon mal mit meiner jetzigen AES-Konfiguration, und zum anderen hing es auch schon mal, was sich aber nach dem Rausholen und Wiedereinsetzen der Batterie beheben ließ, was aber kaum eine Lösung sein kann. An meiner AES-Konfiguration sollte es nicht liegen, denn ich betreibe auch noch eine HM-RC-Key4-2 und einen HM-LC-Sw1-Pl-CT-R1 seit ein paar Wochen stabil mit derselben AES-Konfiguration. Auch bei denen taucht gelegentlich "aesCommToDev: pending" in den Logs auf, aber deutlich seltener und immer gefolgt von "aesCommToDev: ok".

Hat der Sensor grundsätzlich ein Problem mit AES oder ist das Ding schlicht defekt?

Pfriemler · 17 Dezember 2016, 22:37:19

16.12.: battery low. Wechsle doch mal die Knopfzelle im Sensor und schaue dann nochmal ...
Mein Neigungssensor arbeitet zwar seit zwei Wochen in diesem Zustand, aber ohne AES. Vielleicht bekommt er mit der toten Batterie keine einzige Meldung mehr vollständig zustande.

tndx · 20 Dezember 2016, 22:04:15

Update:

ich habe mir nun frische Batterien besorgt, der Sender sendet wenigstens wieder den richtigen Zustand, allerdings scheint es immer noch nicht mit der AES-Signierung zu stimmen, hier der Logausschnitt ab dem Zeitpunkt des Batterietauschs:

Code Auswählen

---

Man sieht, dass "aesCommToDev" einmal kurz "ok" war, und nun steht es wieder die ganze Zeit auf "pending".

Irgendeine Idee, woran das noch liegen könnte?

tndx · 28 Dezember 2016, 23:34:30

Hallo zusammen,

ich hatte heute wieder Zeit, mich mit dem widerspenstigen Sensor zu beschäftigen. Da er zwischenzeitig normal lief dachte ich mir schon, das hätte sich nach dem Batteriwechsel wieder eingependelt, doch nun stelle ich fest, dass das Ding Probleme macht, sobald der HMUARTLGW läuft.

Ich habe momentan 2 IO-Devices: HMUARTLGW und CUL (nanoCUL Marke Eigenbau), und da der HMUARTLGW auch sonst Probleme macht (z.B. Pairing von Rolladenaktoren), deaktiviere ich ihn schon mal bei solchen Aktionen (Auskommentieren in der fhem.cfg). Heute habe ich die Möglichkeit entdeckt, ihn direkt in der FHEM-UI mittels "set <...> close" zu deaktivieren, und dann lief auch der Neigungssensor wieder, aber nur bis ich den HMUARTLGW wieder aktivierte. Das Ganze ist schön reproduzierbar.

Das Merkwürdige daran ist, dass der HMUARTLGW eigentlich nie an der Kommunikation zum Neigungssensor beteiligt war, da der NanoCUL näher dran und daher besser bzgl. der Empfangswerte ist. Mittlerweile habe ich beim Neigungssensor das Attribut "IOgrp VCCU:nanoCUL" gesetzt, aber es bleibt dabei: sobald der HMUARTLGW an ist, bleibt der Neigungssensor mit "aesCommToDev: pending" hängen und läuft wieder, wenn der HMUARTLGW aus ist.

Kann sich jemand einen Reim darauf machen? Eigentlich habe ich den HMUARTLGW gekauft, um Kompatibilitäts- und AES-Problemen aus dem Weg zu gehen, aber bis jetzt gewinnt immer der NanoCUL. Gibt es beim HMUARTLGW noch bekannte offene Baustellen diesbezüglich?

martinp876 · 29 Dezember 2016, 06:40:56

Sniffe die devicelist mit beiden interfaces parallel. Malm sehen, was passiert.

tndx · 29 Dezember 2016, 23:18:44

OK, hier die Ausgabe nur mit nanoCUL, also wenn's läuft:

Code Auswählen

---

und hier wenn's nicht läuft, also wenn der HMUARTLGW dazugeschaltet wird:

Code Auswählen

---

Wobei 400FE5 und 202C70 meine beiden Handfernbedienungen sind, die an diesem Vorgang nicht beteiligt sind. 202C70 ist im Moment gar nicht im Betrieb, da sie wohl nach einem mißglückten Schlüsseltausch ein Totalschaden ist, 400FE5 aber ansonsten einwandfrei läuft.

Die gleiche Fehlermeldung ("You have probably forced an unknown aesKey for this device") sehe ich übrigen schon mal im Log auch für 3 meiner Rolladenaktoren (immer dieselben, die ich nicht als Bausatz gekauft habe), die gar nicht mit AES laufen (darum habe ich mich auch noch nicht darum gekümmert).

Nur zur Sicherheit:
Aus den geposteten Nachrichten lassen sich meine AES-Schlüssel nicht bestimmen, ich muss also keine Schlüsseltauschaktion starten? Das ist das, was eh jeder mit einem geeigneten Equipment vor meiner Haustür mitsniffen kann?

tndx · 03 Januar 2017, 23:06:10

Hallo zusammen,

kann jemand was mit den Logs anfangen? Falls irgendwelche Informationen fehlen, reiche ich die selbstverständlich nach!

Pfriemler · 03 Januar 2017, 23:31:42

Ja ne - AES ist (nicht) meine Baustelle. Sonst gern, aber ich kann einfach nicht mitreden.

Otto?

martinp876 · 04 Januar 2017, 09:19:57

Nun fhem sendet aesreq und das device antwortet im ersten Fall, im 2. Nicht.
Koennte 2 Gründe haben. Entweder ist der Key falsch. Wenn es manchmal geht sollte es nicht zutreffen da manchmal OK hier nicht zutrifft.
Oder das Timing ist Schrott. Nanocul kenne ich nicht. Alle anderen cul und cuno haben für hm ein Timestamp Interface von Ansgar erhalten (tscul). Fw und Modul zusammen bringen es.
Wie das bei der nanocul aussieht kann ich nicht sagen. So wie es jetzt in den logs aussieht gibt es kein vernünftiges Timing. Da es von Rudi nicht angepasst wird musst du bei Ansgar nachfragen

Zum Problem: bei AES gibt es einen Austausch: hin,her,hin,her. Ohne AES nur hin,her. Damit macht AES ein korrektes Timing dringend notwendig.

tndx · 04 Januar 2017, 16:59:11

@Martin: aber dass das Problem reproduzierbar nur bei einem zugeschalteten HMUARTLGW auftritt, tut hier nichts zur Sache? Wie lassen sich die anderen Fehlermeldungen bzgl AES im 2. Log erklären?

Pfriemler · 04 Januar 2017, 20:55:53

Ja, das komische ist ja dass es mit dem nanoCul stabil läuft, aber sobald HMUARTLGW dazu kommt, hakt es, obwohl das HM gar nicht beteiligt ist. Doch Timingprobleme?
Hast Du schon mal versucht, den nanoCUL herauszunehmen und nur mit dem HMUARTLGW zu arbeiten? bei rssi bis -70 wäre das ja kein Problem.
Trotzdestonichts: der HMUARTLGW sollte so oder so stabiler laufen als der nanoCUL, sonst ist das was faul.

tndx · 06 Januar 2017, 10:30:29

Mit dem HMUARTLGW alleine habe ich es noch nicht probiert, denn er ist bei mir empfangstechnisch schlecht platziert und würde alleine nicht alle Devices erreichen. Außerdem habe ich mit dem Ding noch diverse andere Probleme wie die bereits angesprochenen AES-Meldungen im Logfile und Probleme beim Pairing mit Aktoren.

Was mir im Nachhinein aufgefallen ist: Ich hatte zwar beim Sniffen den NanoCUL geschwätzig gemacht, aber nicht den HMUARTLGW, so dass die Protokolle möglicherweise unvollständig sind, ich werde das bei Gelegenheit nachholen.

Pfriemler · 06 Januar 2017, 10:58:20

Heute morgen aufgefallen: Da gibt es doch noch jemanden, der arge Probleme mit AES und unterschiedlichen IOs hat. Ich wollte Dich mal darauf hinweisen - vielleicht liest Du es ja schon, vielleicht kommen Dir Sachen bekannt vor oder sind nachvollziehbar.
Bei Pairing und Firmwareupdates mache ich in letzter Zeit regelmäßig den HMLAN aus, damit es gleich beim ersten Mal klappt

Auch und gerade fürs Sniffen ist das natürlich hilfreich.

tndx · 06 Januar 2017, 11:21:43

Zitat von: Pfriemler am 06 Januar 2017, 10:58:20
Heute morgen aufgefallen: Da gibt es doch noch jemanden, der arge Probleme mit AES und unterschiedlichen IOs hat. Ich wollte Dich mal darauf hinweisen - vielleicht liest Du es ja schon, vielleicht kommen Dir Sachen bekannt vor oder sind nachvollziehbar.

Ist mir auch nach meiner letzten Antwort aufgefallen. Eine Schlussfolgerung für mich ist: es kann zu Problemen kommen, wenn es bei der AES-signierten Kommunikation zum Wechsel des IO-Devices kommt. Das ist bei mir, glaube ich, noch nicht ganz ausgeschlossen, da muss ich noch mal testen. Leider hat der fest verbaute Neigungssensor nur einen Sendeversuch, im Gegensatz zu einer Fernbedienung, bei der die AES-Signierung beim 2. Klick doch funktioniert...

Zusätzlich werde ich mir wohl noch die TimeStamp-Option ansehen.