HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

Begonnen von chipmunk, 18 September 2015, 13:32:39

Vorheriges Thema - Nächstes Thema

RalfRog

Muss der Raspi stromlos werden oder kannst du nicht einen "shutdown -r" initiieren?

Ich hab mein HM-MOD-RPI-PCB schon ein paar Jahre auf dem GPIO im Einsatz.
Ich meine mich zu erinnern, dass da eine bestimmte FW drauf sein muss/soll.
Ich weiß aber echt nicht mehr welche Probleme eine Nichtbeachtung verursacht.

FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

hauwech

Ja, er ist nur nach "stromlos" wieder für eine Zeit erreichbar, reboot nützt nix. Dieser UART und zwei andere sind seit Jahren im Einsatz, ohne Probleme. Bis zu dem beschriebenen kurzen Stromausfall im Haus. Seitdem spinnt dieser Eine.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

RalfRog

#242
Zitat von: hauwech am 14 April 2023, 16:30:45...Ich habe eben mal den neuen HmUART Bausatz zusammengelötet und an ein D1 Board mit ESP8266 gesteckt. Ich habe esp-link draufgepackt und ins WLAN eingebunden. Wenn ich den jetzt nach Wiki über Port 23 anspreche, sehe ich das gleiche Theater wie mit dem anderen spinnerten UART: init/disconnected mit "... did not respond..." im Log...

Ist auch merkwürdig. Komplett neue HW - gleiches Problem?

Lass die Vorschläge von @MadMax-FHEM nicht ausser acht (vcgencmd) ich hatte mit der Spannung auch mal sporadische Schwierigkeiten und dann statt Steckernetzteil ein 5V Netzteil mit regelbarem Ausgang von MeanWell verwendet.

Achja FW. War nicht so dramatisch. Nur: " Firmware 1.4.1 ist die minimal lauffähige Version"

Edit: Schau mal hier -> https://forum.fhem.de/index.php?msg=1126337 ("In den Readings von dem Device wechselt cond von init zu disconnected und dies hin und her.")



Ich vesteh dich. Da geht was nicht mehr - was immer ging - und es gab ein Ereignis. Da sucht man natürlich in Richtung des wahrscheinlichsten Zusammenhangs.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

hauwech

Das vgencmd kannte ich vorher noch nicht. Auf dem betroffenen Raspi hat es 0x0 geliefert, heißt: alles gut.
Auf dem ESP8266 geht das aber nicht.
Daß fhem mit dem neuen UART am neuen 8266 das gleiche Problem hat - damit habe ich nicht gerechnet. Mit telnet kann ich auch mit dieser Instanz verbinden, das läuft also und ist erreichbar. Das würde danach riechen, daß sich hier ein oder mehrere Probleme überschneiden. Die anderen UARTs funktionieren aber weiterhin ohne Probleme, was fhem als mögliche Ursache ausschließt. Daß das gleiche Problem mit anderer Hardware auf fhem Seite das gleiche Bild ergibt, holt fhem als mögliche Ursache wieder ins Boot und scheint ein Hardwareproblem auszuschließen.
Ich muß jetzt nur noch den gemeinsamen Nenner finden.  :)

Wenn ich morgen Zeit habe, muß ich nochmal einen Versuch starten, fhem upzudaten. Es ist immer gut, für eine Forum-gestützte Ursachenforschung ein aktuelles System zu haben.
Das System Update auf ein aktuelles Ubuntu schiebe ich schon lange vor mir her, weil ich weiß, das macht mir jede Menge Probleme. Für den absoluten Notfall habe ich noch eine VM mit einem neueren Ubuntu und fhem im Cold Standby. Mit einer VM würde aber mein Sensor am Stromzähler nicht laufen, der hängt über USB an meinem NUC, auf dem mein fhem läuft.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Ich habe mein fhem-dev auf den neuesten Stand gebracht. Das ist noch jungfräulich und läuft derzeit mit Ubuntu 21.04.
Auch dort gibt es keine Chance, den neuen UART ans Laufen zu kriegen. Das gleiche Theater: init/disconnect und "did not respond". Auch von da aus geht telnet zum 8266.
So langsam glaube ich, daß der neue UART selbst kaputt ist, oder die Kombination mit dem ESP8266MOD 12F und esp-link macht Probleme.
Was passiert, wenn noch mehr der aktiven UARTs ausfallen? Dann kann ich meine gesamte Homematic Installation in die Tonne kloppen. Das ist alles gar nicht gut.
Gibt es eigentlich noch andere Alternativen zum ehemaligen HM-config-LAN?

Gruß0 Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

Otto123

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

frank

ich würde mal einen von den beiden problematischen hmuarts mit einem der 3 funktionierenden tauschen.
in der umgebung sollte er dann eigentlich auch funktionieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

hauwech

Könnte man machen, aber wenn mir noch einer aussteigt, habe ich ein Problem. Ich fasse das nicht an, bis ich den fünften laufen habe. Ich teste noch drei andere D1 Mini, die kommen heute. Wenn der neue UART dann auch nicht reagiert, werde ich bei ELV nachfragen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Das ist spannend: Ich habe nun den neuen HMUART an einen D1 Mini angeschlossen, esp-link draufgepackt und ... geht auf Anhieb!
Ich hatte den UART am D1 Board an die gleichen GPIOs angeschlossen wie jetzt am D1 Mini. Das D1 Board hat das Format vom R3, es ist aber auf beiden der gleiche ESP8266MOD 12-F Chip von AZ-Delivery drauf. Die Pins sind aber laut PinOut tatsächlich unterschiedlich belegt. Vielleicht hätte ich den UART am D1 Board an D10/D11 anschließen müssen. In esp-link kann man die GPIOs leider nicht konfigurieren. Naja: wieder mal was dazu gelernt.
Was mir noch aufgefallen ist: Der "neue" HmUART von ELV wurde tatsächlich noch mit Firmware V. 1.2.1 ausgeliefert. Das Update auf 1.4.1 ging aber geschmeidig.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

RalfRog

Ja aber...

Das mit den PINs erklärt die gescheiterten Versuche mit HMUART und den ESPs.
Gibts auch ne Idee zum ursprünglichen Problem... rein Interessehalber.

Zitat von: hauwech am 17 März 2023, 10:39:51Hallo zusammen,
ich hatte am Wochenende einen kurzen Stromausfall, seitdem war einer meiner HM-MOD-RPI-PCB UARTs auf Raspi nicht mehr erreichbar. ...

FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

hauwech

Die PinOuts hätte ich sorgfältiger vergleichen sollen, mein Fehler.
Was die Sache mit dem Stromausfall angeht: Die einzige Idee, die ich hätte wäre, daß vielleicht beim Wiedereinrücken des ausgelösten FI Spannungsspitzen durchs Netz gegangen sind, wenn alle Standby-Geräte zusammen wieder hochkommen. Aber das ist Kaffeesatzleserei.
Ich habe aber endlich entdeckt, was ich die ganze Zeit übersehen habe. Der spinnerte UART war der Einzige, der noch mit Firmware 1.2.1 lief. Als mir an dem neuen UART aufgefallen ist, daß der noch 1.2.1 drauf hat, habe ich - endlich  ::) - gezielt nach den Firmware Versionen geschaut. Ich habe ihn jetzt auf 1.4.1 gebracht. Mal sehen, ob das Problem damit erledigt ist. Dann kann ich die wackelige Theorie mit den Spannungsspitzen wieder von der Verdachtsliste streichen.

Es ist wie so häufig, daß ein Teil des Problems vor dem Gerät sitzt  ;D Vielleicht kann mein Geständnis andere davor bewahren, meine Fehler zu wiederholen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Update:
Der alte, problematische UART läuft jetzt seit zwei Tagen nach dem Firmware Update. Mal sehen, wann der wieder aussteigt.
Interessant ist, daß der neue UART am D1 Mini drei Tage lang problemlos lief. Heute vormittag hat er dann das init/disconnected Spielchen begonnen. Und auch da hilft nur stromlos machen. Close/open, reopen oder restart am UART oder Reboot des ESP nützt nichts.
Besonders frustrierend daran ist, daß drei der alten UARTs viele Jahre ohne Probleme und zuverlässig gearbeitet haben, bis der eine davon nach dem kurzen Stromausfall angefangen hat, Probleme zu machen. Das kann natürlich passieren. Aber wenn sich auch neue Teile nicht zuverlässig in Betrieb nehmen lassen, ist das schon was Anderes. Ich hatte zwei Neue gekauft. Einer steckt an einem alten Raspi1, hatte Firmware 1.4.1 drauf und läuft. Der andere Neue hatte 1.2.1 drauf und macht sowohl an zwei getesteten Raspis als auch am ESP Probleme. Das Vertrauen hat jedenfalls stark gelitten. Zuverlässige IOs sind das Fundament der ganzen Anlage.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

hauwech

Nach dem Firmware Update scheint der UART zu laufen. Er war heute Nacht mal "disconnected", aber jetzt kommt er wieder zurück auf "ok". Ich habe mir ein notify gebaut, das mir bei Änderung von "cond" auf allen eine Telegram Nachricht schickt. Ein rückwirkender Blick ins fhem Log bestätigt aber, daß offenbar alle HmUARTs immer wieder mal kurz disconnecten, aber dann eben wieder auf ok gehen.
Auf jeden Fall bin ich nun etwas entspannter, weil offenbar auch der ESP-UART sauber läuft. Jetzt muß ich nur noch das "USR-TCP232-T2 Serial TTL to Ethernet Module" testen.

Gruß Roland
Fhem auf Intel NUC11TNKi5+M2 NVMe+32GB RAM mit Ubuntu 22.04 LTS

Capu

Hab auch nen HM-MOD-RPI-PCB mit nem AZDelivery Wemos Klon am laufen. Habe aber statt esp-link tasmota verwendet.
Läuft seit über nem Jahr absolut problemfrei im WLAN.

HowTo und Erfahrungsbericht
Server: Raspberry 3B+ - USB-SSD (Raspian Stretch) - HM-MOD-RPI-PCB - 433MHz@GPIO - MQTT2
Support: Raspberry (Raspian Stretch) - lepresenced - slaesh's CC2652RB - zigbee2mqtt
Stuff: HM-Thermostate, -Dimmer, -Schalter, -Fensterkontakte, 433MHz-"Baumarktsteckdosen", Aqara Sensoren/Switches

reibuehl

Ich hab Probleme meinen HM-MOD_RPI-PCB mit der 1.4.1 Firmware zu flashen. Er hängt am Hardware Serial Port eines Olimex ESP32-POE und wird in FHEM mit Seriennummer und Version angezeigt, daher vermute ich mal, das die Konfiguration so in Ordnung ist. Wenn ich dann wie im Wiki beschrieben ein Update mit set HMLANGW1 updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3 mache, geht er in eine Loop wie im untenstehenden Log-Auszug. Mache ich da was falsch?

2023.07.08 12:03:59 1: HMUARTLGW HMLANGW1 starting firmware upgrade
2023.07.08 12:04:09 1: HMUARTLGW HMLANGW1 did not respond for the 1. time, resending
2023.07.08 12:04:12 1: HMUARTLGW HMLANGW1 did not respond for the 2. time, resending
2023.07.08 12:04:15 1: HMUARTLGW HMLANGW1 did not respond for the 3. time, resending
2023.07.08 12:04:18 1: HMUARTLGW HMLANGW1 did not respond after all, reopening
2023.07.08 12:04:18 3: HMLANGW1 device closed
2023.07.08 12:04:18 1: 192.168.1.193:23 reappeared (HMLANGW1)
2023.07.08 12:04:19 1: HMUARTLGW HMLANGW1 starting firmware upgrade
2023.07.08 12:04:29 1: HMUARTLGW HMLANGW1 did not respond for the 1. time, resending
2023.07.08 12:04:32 1: HMUARTLGW HMLANGW1 did not respond for the 2. time, resending
2023.07.08 12:04:35 1: HMUARTLGW HMLANGW1 did not respond for the 3. time, resending
2023.07.08 12:04:38 1: HMUARTLGW HMLANGW1 did not respond after all, reopening
2023.07.08 12:04:38 3: HMLANGW1 device closed

define HMLANGW1 HMUARTLGW uart://192.168.1.193:23
#   CFGFN     
#   CNT        2
#   Clients    :CUL_HM:
#   DEF        uart://192.168.1.193:23
#   DEVCNT     1
#   DevState   200
#   DevType    UART
#   DeviceName 192.168.1.193:23
#   FD         32
#   FUUID      64a93208-f33f-3bc6-b2c2-0e5637b067460f26
#   FirmwareBlock 1
#   FirmwareFile /opt/fhem/FHEM/firmware/coprocessor_update.eq3
#   LastOpen   1688811139.73384
#   NAME       HMLANGW1
#   NOTIFYDEV  global
#   NR         144681
#   NTFY_ORDER 47-HMLANGW1
#   PARTIAL   
#   RAWMSG     0402436F5F4350555F424C
#   STATE      opened
#   TYPE       HMUARTLGW
#   XmitOpen   0
#   eventCount 188
#   model      HM-MOD-UART
#   Helper:
#     AckPending:
#       2:
#         cmd        056893447B2633AEA92FE95CC764B9D6400AB2886385CC33FD9A91DB61F91B4E5C02B0CA229FE1446950DB3330CD980D78BD296C26591C6C792DA03622422BF62D58C5063E12091DE648ECFD6EA945E0E358A64A64FDC16F3043D0E8D8A4A28470E478AAD04B6FF616472703B49ABF9FFC87ADDA91DDF590E1E0FA1B2447904D858380F03A688396521289AAC9D3399672541D262B78A70C10F1EF166F95CC111F2BD806B19AEC01A841A5689241ABD3702DAD924C566E5929A7DA92CC218B1C252022B369FD4F479160C7466479E2C0B5ECCE0446289F7323522DA3836B09974E33C2E20431D1C76867B5189531C9823AA179868942681CB3B80810266EA7A609DBBEA3231581C358DC9629915CC2FD3525F166AD05959DE62FE95B67426AC1C25A4A7406656AD997494B829E6EF9C065FC88417618CD7E7C7E78E4E476FEE64A8605CEAA4543AC04A8807FA32A7A389F6A81D2DC0016B5A4F442800B19C89D633ACEBFC6ABE01EF967B52893E554597C70447672B6A6AD4939EF1CD2484AF23CFF92FC80B63F0321F589DF762AE9EE7771CF32BA13D789137E3C93158FADFA1FDAD28C3F2CC0D446FAFCADA2ACDACFD10010BD9ED0BE9E1DC69A2C5329BFE2A3A7830A6C790B8A9E1230C8A4FE87A40BD9EB533C579CE78C103C61CFA5A2A0A36883F19F7DD58E63F04A23C5F8236084138371DB1D31799BF8301C60439033A05201BF23FE49C8DC67E25C825956EB888E99716F9524EA8E09298082496C824966D2CFB17A1533F90392B0F381178215FF0135F374C592A8C924CFB5882DD0B19326B8E5EAB81AAB60D963946E6D6CAAE89E9638AEBB7FAAD6E867292EF7EE8CCE9EFC42B1C1712E5054CFFA36ACF477162010D847F2A09564CD53F18C81E4B083274A2C2C10D992A72693F3D4048ACB8E98B458E8A06F331FE3D04A27D8D34A2FDE6E8DEFED8DCE22EAB25C2434B2F4CEAEA6ED5EEC81C1A3927004EBB976E27C54508BE59DEE3253FFE1B1A9EFC2F331D42F3BE3738FFAD706C572A2ED9C5F512FB4D2864B67AF59337358FC45D0A8CC8719E488AC7F574780D31F20EC738AF1B16195D05325E431B93F35410ABFC71A900F7B00693542E4E44C32BFB33C35A310979A6697D3BB99C6488B57F048443387DF8802F93444C61765367533441C150408EAF422CAD78569EF39DB9D771BC8581838ACDC6653E53A5DCCD413835B0DED38C63B23993DDE07683EA5C9DEE0C26B261C118485FBAD3241EBDB26B818EB873843CEC2DE8BF0FDD252147E2FD6AEC949E7E1D1304857254E0F5CC946FB10B286F591581D59C86D76A97454A82C38F2875D67FC3373AEB57EF00BCBB7D12123ED5D29FF5893FE6ED2A870606B9161A126650A74436C6C75ABC9FA91E3AB58DDBDCA6806D15B68E6D224E9959E8EB09EB7AC80CE9AEE67BF58075D8AC639B48974358089A1CA10F61A079116D7E3
#         dst        0
#         frame      FD04130002056893447B2633AEA92FE95CC764B9D6400AB2886385CC33FD9A91DB61F91B4E5C02B0CA229FE1446950DB3330CD980D78BD296C26591C6C792DA03622422BF62D58C5063E12091DE648ECFD6EA945E0E358A64A64FDC16F3043D0E8D8A4A28470E478AAD04B6FF616472703B49ABF9FFC87ADDA91DDF590E1E0FA1B2447904D858380F03A688396521289AAC9D3399672541D262B78A70C10F1EF166F95CC111F2BD806B19AEC01A841A5689241ABD3702DAD924C566E5929A7DA92CC218B1C252022B369FD4F479160C7466479E2C0B5ECCE0446289F7323522DA3836B09974E33C2E20431D1C76867B5189531C9823AA179868942681CB3B80810266EA7A609DBBEA3231581C358DC9629915CC2FD3525F166AD05959DE62FE95B67426AC1C25A4A7406656AD997494B829E6EF9C065FC88417618CD7E7C7E78E4E476FEE64A8605CEAA4543AC04A8807FA32A7A389F6A81D2DC0016B5A4F442800B19C89D633ACEBFC6ABE01EF967B52893E554597C70447672B6A6AD4939EF1CD2484AF23CFF92FC80B63F0321F589DF762AE9EE7771CF32BA13D789137E3C93158FADFA1FDAD28C3F2CC0D446FAFCADA2ACDACFD10010BD9ED0BE9E1DC69A2C5329BFE2A3A7830A6C790B8A9E1230C8A4FE87A40BD9EB533C579CE78C103C61CFA5A2A0A36883F19F7DD58E63F04A23C5F8236084138371DB1D31799BF8301C60439033A05201BF23FE49C8DC67E25C825956EB888E99716F9524EA8E09298082496C824966D2CFB17A1533F90392B0F381178215FF0135F374C592A8C924CFB5882DD0B19326B8E5EAB81AAB60D963946E6D6CAAE89E9638AEBB7FAAD6E867292EF7EE8CCE9EFC42B1C1712E5054CFFA36ACF477162010D847F2A09564CD53F18C81E4B083274A2C2C10D992A72693F3D4048ACB8E98B458E8A06F331FE3D04A27D8D34A2FDE6E8DEFED8DCE22EAB25C2434B2F4CEAEA6ED5EEC81C1A3927004EBB976E27C54508BE59DEE3253FFE1B1A9EFC2F331D42F3BE3738FFAD706C572A2ED9C5F512FB4D2864B67AF59337358FC45D0A8CC8719E488AC7F574780D31F20EC738AF1B16195D05325E431B93F35410ABFC71A900F7B00693542E4E44C32BFB33C35A310979A6697D3BB99C6488B57F048443387DF8802F93444C61765367533441C150408EAF422CAD78569EF39DB9D771BC8581838ACDC6653E53A5DCCD413835B0DED38C63B23993DDE07683EA5C9DEE0C26B261C118485FBAD3241EBDB26B818EB873843CEC2DE8BF0FDD252147E2FD6AEC949E7E1D1304857254E0F5CC946FB10B286F591581D59C86D76A97454A82C38F2875D67FC3373AEB57EF00BCBB7D12123ED5D29FF5893FE6ED2A870606B9161A126650A74436C6C75ABC9FA91E3AB58DDBDCA6806D15B68E6D224E9959E8EB09EB7AC80CE9AEE67BF58075D8AC639B48974358089A1CA10F61A079116D7E3140C
#         resend     3
#         time       1688811140.76395
#     DBLOG:
#       cond:
#         logdb:
#           TIME       1688811140.75955
#           VALUE      fwupdate
#       state:
#         logdb:
#           TIME       1688811139.73578
#           VALUE      CONNECTED
#     LastSendLen:
#       3
#       1043
#     Log:
#       IDs:
#     RoundTrip:
#   MatchList:
#     1:CUL_HM   ^A......................
#   Peers:
#   READINGS:
#     2023-07-08 12:01:10   D-HMIdOriginal  753366
#     2023-07-08 12:01:10   D-firmware      1.2.1 (outdated)
#     2023-07-08 12:01:10   D-serialNr      SEQ1777878
#     2023-07-08 11:53:12   D-type          HM-MOD-UART
#     2023-07-08 12:12:20   cond            fwupdate
#     2023-07-08 12:03:58   load            0
#     2023-07-08 12:01:18   loadLvl         suspended
#     2023-07-08 12:12:19   state           opened
#
setstate HMLANGW1 opened
setstate HMLANGW1 2023-07-08 12:01:10 D-HMIdOriginal 753366
setstate HMLANGW1 2023-07-08 12:01:10 D-firmware 1.2.1 (outdated)
setstate HMLANGW1 2023-07-08 12:01:10 D-serialNr SEQ1777878
setstate HMLANGW1 2023-07-08 11:53:12 D-type HM-MOD-UART
setstate HMLANGW1 2023-07-08 12:12:20 cond fwupdate
setstate HMLANGW1 2023-07-08 12:03:58 load 0
setstate HMLANGW1 2023-07-08 12:01:18 loadLvl suspended
setstate HMLANGW1 2023-07-08 12:12:19 state opened

Reiner.