HMW-IO-12-Sw14-DR Analogeingang

[hennejg]

Ich habe mit einem Analogeingang an einem HMW-IO-12-Sw14-DR ein Problem, das mich nun schon sehr viel Zeit gekostet hat. Das Problem äußert sich darin, dass bei Änderungen des Eingangssignals relativ häufig kurz bzw. einmalig umplausible Werte gemeldet werden. Der unplausible Wert ist meist 1023, manchmal aber auch 0. Ich habe das zunächst für Tansienten/Störungen auf dem Eingangssignal gehalten und viel Zeit damit verbracht, es zu säubern, abzuschirmen usw., aber schießlich festgestellt, dass das Problem auch dann auftritt, wenn ich ein garantiert sauberes, ausreichend niederohmiges Signal anliefere.

Evtl. ist das Problem verwandt mit diesem: https://forum.fhem.de/index.php/topic,76701.msg686088.html#msg686088

Ist dieses Problem schon anderweitig aufgetaucht?

Update:
Ich kann inzwischen ergänzen, dass die fehlerhaften Werte immer genau dann auftreten, wenn das Eingangssignal die Schwelle von 5V passiert. Wird die Schwelle aufsteigend passiert, wird der Wert 1023 reported, absteigend der Wert 0. Dies bringt mich zu dem Verdacht, dass ein Zusammenhang mit der Betriebsart als digitaler Eingang bestehen könnte.

Bei Interesse kann ich auch Debug-Logs eines solchen Falls bereitstellen.

Update 2:
Die Schwelle scheint eher bei 5,12V bzw. dem Wert 512 zu liegen. Das Log ist unauffällig, d.h. die rohen Messages von dem Device lassen keinen offensichtlichen Rückschluss darauf zu, dass es sich um irgendwie "andersartige" Werte handelt. Hier ein kommentierter Auszug aus einer Kombination von Debug-Log und Event-Log:

Code Auswählen Erweitern


# Letzer korrekter Wert vor dem Sprung
2019.09.12 16:58:35.841 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2019.09.12 16:58:35.842 4: hm485: Event:HASH(0x240ac08)
2019.09.12 16:58:35.843 5: hm485: Dispatch: FD0F0065000000015A0001B813691401F0
2019.09.12 16:58:35.843 5: hm485: dispatch ▒\017\000e\000\000\000\001Z\000\001▒\023i\024\001▒
2019.09.12 16:58:35.844 5: hm485: HM485_Parse: MsgId: 0
2019.09.12 16:58:35.844 5: hm485: HM485_Parse: ProcessEvent
2019.09.12 16:58:35.845 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 691401F0

2019-09-12 16:58:35.865 HM485 myFooValue value: 496.00

# Spring "aufwärts" über die Schwelle: 1x Reporten von 1023.
    2019.09.12 16:58:43.415 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
    2019.09.12 16:58:43.416 4: hm485: Event:HASH(0x2552508)
    2019.09.12 16:58:43.416 5: hm485: Dispatch: FD0F0065000000011A0001B813691403FF
    2019.09.12 16:58:43.417 5: hm485: dispatch ▒\017\000e\000\000\000\001\032\000\001▒\023i\024\003▒
    2019.09.12 16:58:43.417 5: hm485: HM485_Parse: MsgId: 0
    2019.09.12 16:58:43.418 5: hm485: HM485_Parse: ProcessEvent
    2019.09.12 16:58:43.418 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 691403FF

    2019-09-12 16:58:43.438 HM485 myFooValue  value: 1023.00

# Folgender, korrekter Wert
2019.09.12 16:58:43.461 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2019.09.12 16:58:43.461 4: hm485: Event:HASH(0x245c608)
2019.09.12 16:58:43.462 5: hm485: Dispatch: FD0F0065000000011C0001B81369140202
2019.09.12 16:58:43.463 5: hm485: dispatch ▒\017\000e\000\000\000\001\034\000\001▒\023i\024\002\002
2019.09.12 16:58:43.463 5: hm485: HM485_Parse: MsgId: 0
2019.09.12 16:58:43.464 5: hm485: HM485_Parse: ProcessEvent
2019.09.12 16:58:43.464 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 69140202

2019-09-12 16:58:43.483 HM485 myFooValue  value: 514.00

# Wert vor Spung abwärts
2019.09.12 16:58:49.722 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2019.09.12 16:58:49.722 4: hm485: Event:HASH(0x259fe00)
2019.09.12 16:58:49.722 5: hm485: Dispatch: FD0F0065000000011C0001B8136914020E
2019.09.12 16:58:49.723 5: hm485: dispatch ▒\017\000e\000\000\000\001\034\000\001▒\023i\024\002\016
2019.09.12 16:58:49.724 5: hm485: HM485_Parse: MsgId: 0
2019.09.12 16:58:49.724 5: hm485: HM485_Parse: ProcessEvent
2019.09.12 16:58:49.724 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 6914020E

2019-09-12 16:58:49.743 HM485 myFooValue  value: 526.00

# Sprung mit 1x Reporten von 0
    2019.09.12 16:58:51.333 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
    2019.09.12 16:58:51.333 4: hm485: Event:HASH(0x2552bc8)
    2019.09.12 16:58:51.333 5: hm485: Dispatch: FD0F0065000000011C0001B81369140000
    2019.09.12 16:58:51.334 5: hm485: dispatch ▒\017\000e\000\000\000\001\034\000\001▒\023i\024\000\000
    2019.09.12 16:58:51.335 5: hm485: HM485_Parse: MsgId: 0
    2019.09.12 16:58:51.335 5: hm485: HM485_Parse: ProcessEvent
    2019.09.12 16:58:51.336 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 69140000

    2019-09-12 16:58:51.356 HM485 myFooValue  value: 0.00

# folgender, korrekter Wert
2019.09.12 16:58:51.357 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 0 Cmd: 101
2019.09.12 16:58:51.358 4: hm485: Event:HASH(0x2555fe0)
2019.09.12 16:58:51.358 5: hm485: Dispatch: FD0F0065000000011E0001B813691401FA
2019.09.12 16:58:51.359 5: hm485: dispatch ▒\017\000e\000\000\000\001\036\000\001▒\023i\024\001▒
2019.09.12 16:58:51.359 5: hm485: HM485_Parse: MsgId: 0
2019.09.12 16:58:51.360 5: hm485: HM485_Parse: ProcessEvent
2019.09.12 16:58:51.360 5: hm485: HM485_ProcessEvent: hmwId = 0001B813 msgData = 691401FA

2019-09-12 16:58:51.379 HM485 myFooValue  value: 506.00


[Thorsten Pferdekaemper]

Hi,
diese Symptome klingen für mich eher nach etwas "elektrischem". Ich halte es für sehr unwahrscheinlich, dass das irgendwo in FHEM schiefläuft. ...vor allem wenn das nur bei einem bestimmten Eingang passiert. Das fühlt sich dann eher so an, als ob der zugehörige A/D-Wandler einen Knacks hat.
Hast Du schonmal das ganze Gerät ausgetauscht?
Gruß,
   Thorsten

[hennejg]

Hallo Thorsten

danke für die Einschätzung. Dass es ein analoges elektrisches Problem ist, halte ich für extrem unwahrscheinlich. Dafür ist der Punkt, an dem der Glitch Auftritt, 512, zu konstant und zu "digital". Das Problem betrifft auch nicht nur einen Eingang, sondern alle. In FHEM selbst liegt das Problem sicher auch nicht, denn das Log zeigt klar, dass die fehlerhaften Messages schon von dem Modul kommen. Bleiben aus meiner Sicht noch drei Optionen:
- alle AD-Wandler-Channela haben ein Problem
- die Firmware des Moduls hat ein Problem
- das HMW-Modul für FHEM konfiguriert das Gerät falsch (habe mir den Code grob angeschaut, aber nichts gesehen)

Grüße
Jörg Henne

[Thorsten Pferdekaemper]

Dass es ein analoges elektrisches Problem ist, halte ich für extrem unwahrscheinlich. Dafür ist der Punkt, an dem der Glitch Auftritt, 512, zu konstant und zu "digital".

Ich hatte gar nichts von "analog" geschrieben.

Das Problem betrifft auch nicht nur einen Eingang, sondern alle. In FHEM selbst liegt das Problem sicher auch nicht, denn das Log zeigt klar, dass die fehlerhaften Messages schon von dem Modul kommen. Bleiben aus meiner Sicht noch drei Optionen:
- alle AD-Wandler-Channela haben ein Problem

Wenn das so ähnlich funktioniert wie beim Arduino, dann hat das Ding intern im Endeffekt sowieso nur einen A/D-Wandler und die Eingänge gehen über einen Multiplexer. D.h. wenn es tatsächlich am A/D-Wandler liegt, dann für alle Kanäle.

- die Firmware des Moduls hat ein Problem

Das würde mich ein bisschen wundern, dann dann gäbe es das ja öfters. (Ich denke in dem anderen Thread war es ein anderes Problem.)

- das HMW-Modul für FHEM konfiguriert das Gerät falsch (habe mir den Code grob angeschaut, aber nichts gesehen)

Da wüsste ich jetzt nicht, was man da falsch konfigurieren könnte.

Wie gesagt: Ich würde empfehlen, das Ding mal auszutauschen.

Gruß,
   Thorsten

[Navigator]

Gibt es hier vielleicht Neuigkeiten?  Ich habe genau die selben Phänomene, vor allem bei analogen Feuchtesensoren.

[hennejg]

Gibt es hier vielleicht Neuigkeiten?  Ich habe genau die selben Phänomene, vor allem bei analogen Feuchtesensoren.

Leider nein. Ich bin mir relativ sicher, dass es sich nicht um ein Problem von FHEM bzw. dem HM-Modul handelt, sondern um ein Problem der Firmware des Controllers oder der Hardware. Letztendlich habe ich einen Workaround benutzt, der darauf beruht, das Einganssignal auf den Bereich 0-5,11V zu begrenzen, wodurch der "kritische Punkt" nicht zum Tragen kommt.
Tut mir leid, keine besseren Nachrichten bieten zu können.

[Navigator]

Hmm, keine guten Neuigkeiten. Mir ist aber aufgefallen das dieser Wert von 1023 im selben Moment oder sagen wir kurz nach dem richtigen Wert zu Stande kommt. Das kann man gut im Live Monitor verfolgen. Erst kommt der normale Wert und dann mit dem selben Zeitstempel, der Wert von 1023. Sehr seltsam. Aber bevor ich jetzt wieder an der Elektrik rumfummel, filtere ich die falschen Werte jetzt direkt über FHEM aus.

[hennejg]

Aber bevor ich jetzt wieder an der Elektrik rumfummel, filtere ich die falschen Werte jetzt direkt über FHEM aus.

Ja, in der Tat wäre es eine gute Idee, dies in FHEM auszufiltern. Mir ist es jedoch leider nicht gelungen, dies mit FHEM-Regeln zu lösen. Sprich, ich denke, man müsste das auf Perl-Ebene im HMW-Modul abfangen und korrigieren.

[Navigator]

Ich schreibe ein userReading mit dem, in diesem Fall, Feuchtewert direkt in das HMW Device.  Der Value wird direkt umgerechnet und gefiltert.

Code Auswählen Erweitern

userReadings: humidity {if (ReadingsVal($name,"value","") < 1023 && ReadingsVal($name,"value","") > 0) {sprintf"%.0f", (ReadingsVal($name,"value","")/10)} else {return}}

...der einfache "return" am Ende hab ich noch angehängt damit im Fall der Fälle der Wert nicht "leer" bleibt.

Dann noch ein "event-on-change" und "event-min-interval"l Attribut setzen und schon gehts zufriedenstellend.

[hennejg]

Dann noch ein "event-on-change" und "event-min-interval"l Attribut setzen und schon gehts zufriedenstellend.

Oh, Ok, nice. Danke!

[Navigator]

Heute hab ich den Spuk ein weiteres mal beobachtet und konnte auch mal messen. Ein Analoger Temperatursensor brachte den Wert 1023, fast im Millisekundentakt und verstopfte auch den Bus damit kräftig. Im Eventmonitor konnte man immer einen Wechsel zwischen dieser 1023 und dem richtigen Wert beobachten. Immer in hin und her und das im Dauerfeuer. Ich hab dann mal gemessen und habe am Eingang vom HM Device ca. 6V gemessen. Das Kabel dann abgeklemmt und es war Ruhe, Kabel wieder rein und sofort gibt das von vorn los. Ich habs dann einfach laufen lassen und nach ein paar Minuten war ohne weiteres Zutun alles wieder in Ordnung und das Theater vorbei. Verrückt dieses Verhalten und auch nicht nachvollziehbar für mich.

[Navigator]

.. passend dazu habe ich fogendes gefunden, aber leider keine Antwort von seitens ELV.

Wenn ich am ANALOGEN EINGANG (0 bis 10V) genau 5V oder genau 6V anschließe springt der Wert im HomeMatic WebUI beim Eingangswert immer zwischen den Zahlen 0 und 1000 hin und her.
Wird die Spannung reduziert oder erhöht, dann wird der richtige Wert angezeigt. (zum Beispiel bei 4,65V wird ein Eingangswert von 465 angezeigt)
Ich kann nicht verstehen, warum das nur bei den Spannungen 5V und 6V ist.
Ich weiß nicht was ich falsch gemacht habe bzw. vl. hat auch das Modul einen defekt?
Hat irgendjemand das selbe Problem?

Danke für eure Hilfe

[Navigator]

Update: Ich habe jetzt ein Poti angehängt und kann den Wert von 1023 bei ca. 6.1V simulieren. Gleichzeitig habe ich aber auch mal meinen bei Ebay gekauften Abschlusswiderstand gemessen. Ich komme aber weit in den kOhm Bereich und der sollte doch eigentlich nur 120 Ohm haben.    Was kann ein zu hoher Widerstand eigentlich für Nebenwirkungen haben?

Edit: Zumindest kann dieser kuriose Anstieg auf 1023 etwas mit der Firmware zu tun haben.

Code Auswählen Erweitern

OK, meine 12/14er haben auch angeblich 1.00, ich weiß aber, das ich vor kurzem erst eher zufällig bemerkt hatte, das eines noch eine alte Firmware hatte (die mit dem A/D-Bug um die 5V herum),

[Ralf9]

Gleichzeitig habe ich aber auch mal meinen bei Ebay gekauften Abschlusswiderstand gemessen. Ich komme aber weit in den kOhm Bereich und der sollte doch eigentlich nur 120 Ohm haben.    Was kann ein zu hoher Widerstand eigentlich für Nebenwirkungen haben?

Es ist eher umgekehrt, ein zu niedriger Abschlusswiderstand kann evtl Nebenwirkungen haben.

https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss

Im Gegensatz zu anderen RS485-Bussystemen braucht Homematic Wired keinen echten Busabschluss. Die Datenübertragungsrate ist zu niedrig, als dass es zu Problemen wegen Reflexionen kommt. Wahrscheinlich kann es durch den üblichen RS485-Busabschluss (etwa 120 Ohm zwischen A und B) sogar vorkommen, dass der Bus nicht richtig funktioniert oder sogar Geräte beschädigt werden. Das, was von eq3 als Abschlusswiderstand verkauft wird, ist kein Busabschluss, sondern ein Widerstandsnetzwerk, welches den Bus auf ein definiertes Potential bringt, wenn kein Busteilnehmer sendet. Die genauen Werte können dem obigen Bild entnommen werden.

Gruß Ralf