HBW-1W-T10 auf Arduino...

Begonnen von joachimm, 14 November 2018, 18:49:28

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Hi,
ich habe jetzt den letzten Stand des HM485-Moduls ins Git hochgeladen. Damit müsste jetzt alles erledigt sein.
Gruß,
   Thorsten
FUIP

loetmeister

Hi,

ja danke, sieht gut aus.  8) Habe auch alle XML aktualisiert, die ONEWIRE_TYPE nutzen.
https://github.com/loetmeister/HBWired/commit/d805a9490ae80d89e12cab61614df7b100c7cc11

Gruß,
Thomas

holzwurm83

Hallo Thomas,
hallo Thorsten,

ich habe leider aktuell immer wieder Aussetzer auf dem BUS. Ich habe die Vermutung das es von dem HBW-1W-T10 kommt. Die ausgespielte Firmware müsste so ca. zwei Jahre alt sein, bevor es diese Anpassungen hier gabt. Der Aktor ist 42000017 . Ich habe euch mal dem LOG angehängt. Könnt ihr euch das mal anschauen. Bis vor wenigen Wochen hatte ich eigentlich nicht wirklich Probleme.

Eine andere Frage hätte ich zur Definition des LOGs. Ich habe den wie folgt definiert:
attr HM485_LAN HM485d_logVerbose 5
attr HM485_LAN HM485d_logfile ./log/HM485-%Y-%W.log


Allerdings wird mir nun eine Datei erstellt die genau so heißt "HM485-%Y-%W.log" und nicht eine Datei pro Woche.

Hier ist die Datei:
https://we.tl/t-BzDbrJEYEh

- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

Hi,

könntest zu das log hier im Forum als Zip anhängen? In deinem Link sehe ich nur Werbemüll....

Bzgl. deinem Problem. Was für "Aussetzer" hast du denn? Woran zeigt sich das? Läuft alles problemlos ohne HBW-1W-T10? Was ist geändert worden, wenn "früher" alles ok war? :)

Gruß,
Thomas

holzwurm83

Zitat von: loetmeister am 05 April 2021, 21:50:49
könntest zu das log hier im Forum als Zip anhängen? In deinem Link sehe ich nur Werbemüll....
Habe ich jetzt mal angehängt

Zitat von: loetmeister am 05 April 2021, 21:50:49
Bzgl. deinem Problem. Was für "Aussetzer" hast du denn? Woran zeigt sich das? Läuft alles problemlos ohne HBW-1W-T10? Was ist geändert worden, wenn "früher" alles ok war? :)
Die Aussetzer zeigen sich das die Geräte, die nicht direkt mit einander gepeert sind nicht reagieren. Z.B. ein Taster der nicht direkt gepeert ist lässt das Licht nicht einschalten. Der Tastendruck selbst zeigt sich in Fhem selbst auch nicht. Aus Fhem lässt sich das Licht direkt in dem Fall einschalten.

Komplett ohne HBW-1W-T10 habe ich das noch nicht ausprobiert, aber wenn ich den kurz vom Netz genommen habe ist alles wieder gelaufen.

Wobei ich das bis jetzt noch nicht so 100% rekonstruieren kann. Selbst wenn ich bei einem Aussetzer einfach nichts unternommen habe, ging auch nach einer Zeit alles wieder.


Ich habe einen MacMini Server auf dem Docker läuft. Fhem läuft in einem Container. Der Anfang ist mir nicht mehr ganz klar, aber ich meine das es angefangen hat als ich ein update für Docker gemacht habe.

Ich hatte heute die Vermutung das es evtl. was mit der Verbindung zum BUS selbst zu tun hat und ich evtl. noch einen extra Port freigeben muss. Habe jetzt heute mal noch den Port 2000 für den fhem Container freigegeben.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

Hi,

das log geht über ein paar Tage.... wann gab es denn das Problem?  ???

Was mit beim Überfliegen aufgefallen ist:
42000017 schickt komische Nachrichten an F1FFC703 und 07020017. Was sind das für Zielgeräte? Kannst du bei 42000017 mal alle peerings anzeigen?
608F3FAC schickt eine weile in Kurzer Folge Tastendrücke und Annonce Nachrichten. Ist das richtig? oder Hängt da ein Taster?


Gruß,
Thomas

holzwurm83

Zitat von: loetmeister am 05 April 2021, 23:47:50
das log geht über ein paar Tage.... wann gab es denn das Problem?  ??
Meistens am Abend. So kurz vor Mitternacht, aber das war nicht immer so. In dem Log müsste das auf jeden Fall Nachts passiert sein.

Zitat von: loetmeister am 05 April 2021, 23:47:50
42000017 schickt komische Nachrichten an F1FFC703 und 07020017. Was sind das für Zielgeräte?
Habe gerade einmal nachgeschaut. Ich habe werde ein HBW, noch ein HMW Gerät, dass so heißt.

Zitat von: loetmeister am 05 April 2021, 23:47:50
Kannst du bei 42000017 mal alle peerings anzeigen?
Habe dir dazu ein List angehängt. Ich habe für diese Gerät bislang auch keine Peers eingerichtet.

Zitat von: loetmeister am 05 April 2021, 23:47:50
608F3FAC schickt eine weile in Kurzer Folge Tastendrücke und Annonce Nachrichten. Ist das richtig? oder Hängt da ein Taster?
Da hängt ein IO-Modul dran:
http://www.haus-bus.de/index.php?showHtml=ioModul
An dem ist ein SPS 6-Fachtaster angeschlossen und Bewegungsmelder.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

#67
Hi,

ok, den HBW-IO-12-1W-UP kenn ich... sollte ok sein, wenn der Melder richtig anspricht. Ich weiß nicht ob das den original HMW Geräten entspricht, aber immer eine Announce Nachricht mit zu senden fand ich nicht so gut. (für eine gepeerte Tasten sind das drei Nachrichten: announce, key press Broadcast und peering). Ist aber erst mal egal, denke ich....

bzgl. HBW-1W-T10. Im log ist ab 21:06 komisches zu sehen... habe den String mal etwas zerteilt, da es immer wieder die selben Zeichenfolgen sind....
2021.04.03 21:06:07.311 3: HM485d: Rx:  I[2](0,Y,B)(8C) 42000017 -> F1FFC703 [185] 03()
2C03F123230006059503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7FFF1EC069503
C7FFF1ECB797088F1B00230006069503
C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7FFF1EC069503
C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7 {EDF4}
2021.04.03 21:06:07.313 4: HM485d: Tx: FDC20065F1FFC7038C42000017032C03F123230006059503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7FFF1EC069503C7FFF1ECB797088F1B00230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7FFF1EC069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7


ganz ehrlich, ich wüsste nicht wie und warum HBW-1W-T10 so was raus schicken sollte... der Nachrichten Typ existiert nicht. Ich denke da kommen irgendwie Daten Pakete durcheinander.
Was mir ebenfalls schleierhaft ist, warum FEHM darauf antworten sollte "HM485d: Tx:"... wenn das Ziel "F1FFC703" war, dann wird es ja nicht von der Zentrale quittiert. Eventuell kann Thosten mehr zum Logging sagen.

Würde vorschlagen du läds dir die aktuelle lib und HBW-1W-T10 und aktualisiert das Gerät. Einstellungen und Sensoren sollte gespeichert bleiben. Zu Sicherheit vergleiche mal deine HBW-1W-T10 XML mit der von github. Ab ende 2019 gab es da keine Änderungen mehr, d.h. es hat sich nichts am EEPROM Layout geändert.
(https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10)


Edit:
Noch eine Ergänzung. Ich selber habe HBW-1W-T10 nicht im Einsatz, aber HBW-CC-DT3-T6 und HBW-CC-VD-8 welches den selben Code aus "HBWOneWireTempSensors.h" nutzt. Hab noch nicht beobachtet das der Bus mit Datenmüll geflutet wurde....  ::)


Gruß,
Thomas

holzwurm83

Zitat von: loetmeister am 06 April 2021, 20:38:40

Würde vorschlagen du läds dir die aktuelle lib und HBW-1W-T10 und aktualisiert das Gerät. Einstellungen und Sensoren sollte gespeichert bleiben. Zu Sicherheit vergleiche mal deine HBW-1W-T10 XML mit der von github. Ab ende 2019 gab es da keine Änderungen mehr, d.h. es hat sich nichts am EEPROM Layout geändert.
(https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10)


Ok, danke schon mal. Werde ich mal die Tage mal schauen, ob ich das mal aufspiele.

ZitatIn diesem Fall sollte aber auch im HBW-1W-T10 der parasitären Modus deaktiviert werden.
Muss ich dazu dann noch was umstellen? Ich habe das nicht im parasitären Modus laufen?
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

Wenn du die Sensoren mit +5V (neben Masse und dem Datenpin) verbunden hast, dann wäre es sauberer den parasitären Modus zu deaktivieren. Es läuft aber auch so..

HBWOneWireTempSensors.cpp Zeile 130.
(1 in 0 ändern oder den Parameter löschen...)
ow->write(0x44, 0);

Gruß,
Thomas

holzwurm83

Hallo Thomas,

eine Update habe ich noch nicht durchführen können. Ich habe heute, aber einen kurzen Aussetzer auf dem BUS zeitlich sehr genau eingrenzen können. Wann es genau angefangen hat weiß ich nicht, aber um kurz vor 18Uhr ist es mir aufgefallen und ab 18 Uhr hat wieder alle Funktioniert.

Kannst du dir das im LOG nochmal anschauen ob dir was auffällt?

Danke dir.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

#71
Hi,

also das komische Verhalten was im vorigen Beitrag im log gesehen hatte sehe ich nicht... auch nichts was mit dem Gerät 42000017 zusammenhängt... aber es gibt mehrfach Pausen - bzw. unbekannte/unvollständige Kommunikation in ca. 20 Sekunden Intervallen. Irgendwie wird da hochgezählt... discovery kann es aber eigentlich nicht sein. Habe ich noch nicht gesehen....
EDIT: Es schein ein Keep alive vom hm485 FHEM Modul an den HM485d deamon zu sein. Also wenn sonst keine Kommunikation stattfindet wird so eine Art ping an den HM485d prozess geschickt, welche aber nicht auf den Bus geht (also Rx / Tx nur zwischen FHEM und HM485d)
Im FHEM log sieht man das.... hatte ich mir noch nicht so genau angeschaut ...  ;D
2021.04.08 21:11:47 5: hm485: HM485_LAN_Write TX: 18
2021.04.08 21:11:47 5: SW: fd02124b
2021.04.08 21:11:47 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 18 Cmd: 97
2021.04.08 21:11:47 5: hm485: HM485_LAN_parseIncommingCommand: Alive: (18) 00 AliveStatus: 00

Die Frage bleibt... warum ist für über 30 Minuten ruhe auf dem Bus?
/EDIT

2021.04.08 17:25:08.693 4: HM485d: Rx: FD02714B
2021.04.08 17:25:08.697 4: HM485d: Tx: FD03716100
2021.04.08 17:25:28.706 4: HM485d: Rx: FD02724B
2021.04.08 17:25:28.709 4: HM485d: Tx: FD03726100
2021.04.08 17:25:48.715 4: HM485d: Rx: FD02734B
2021.04.08 17:25:48.718 4: HM485d: Tx: FD03736100
2021.04.08 17:26:08.724 4: HM485d: Rx: FD02744B
2021.04.08 17:26:08.727 4: HM485d: Tx: FD03746100
...
2021.04.08 17:59:50.025 4: HM485d: Rx: FD02D94B
2021.04.08 17:59:50.028 4: HM485d: Tx: FD03D96100



Immer von ca. 25 nach bis zur vollen Stunde. Gibt es da einen Bestimmen Task?

Thorsten Pferdekaemper

Hi,
das Logging sieht für mich ein bisschen danach aus, als ob da irgendein Gerät (oder etwas anderes) auf den Bus rausruft, ohne vorher zu prüfen, ob der Bus busy ist. So etwas in der Art könnte auch die vermeintliche Ruhe auf dem Bus erklären. Der Daemon versucht halt aus dem Datenmüll irgendwas rauszulesen, was er kennt.
Ich glaube, dass man da mal ein Gerät nach dem anderen zeitweise vom Bus nehmen muss und dann sieht, ob eins davon der "Übeltäter" ist.
Hast Du den so genannten "Busabschluss" bei Dir drin?
Gruß,
   Thorsten
FUIP

holzwurm83

Hi,

Danke für euer Feedback!

Zitat von: loetmeister am 08 April 2021, 20:59:32
Immer von ca. 25 nach bis zur vollen Stunde. Gibt es da einen Bestimmen Task?

Muss ich mal auf den Grund gehen, aber ich wüste nicht was das sein sollte. Eine Pumpe im Garten Schaltet immer zur vollen Stunde ein für 15min.

Zitat von: Thorsten Pferdekaemper am 08 April 2021, 21:34:52
Ich glaube, dass man da mal ein Gerät nach dem anderen zeitweise vom Bus nehmen muss und dann sieht, ob eins davon der "Übeltäter" ist.

Ich habe aktuell eine Vermutung das es was mit dem 000094E5 zu tun hat. Das ist ein HMW_SEN_SC_12_DR. Da hängen die Fenster dran. Der Vorfall Heuft sich, wenn ein Fenster einmal offen war.

Zitat von: Thorsten Pferdekaemper am 08 April 2021, 21:34:52
Hast Du den so genannten "Busabschluss" bei Dir drin?

Ja, der ist verbaut. Ohne laufen nicht alle Autoren.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

holzwurm83

Hallo Thorsten,

hat mein Problem evtl. auch damit zu tun?

https://forum.fhem.de/index.php/topic,120277.0.html

Meine Fhem Version ist auch jeden Fall auf einem Stand von 2021.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN