Hi,
kennt jemand das Teil?
Funktioniert es mit HMLAND?
Es sieht nach einer Alternative zum USB-Stick aus.
Danke
Chipmunk
ZitatFunktioniert es mit HMLAND?
Aktuell vermutlich noch nicht. sollte aber machbar sein.
Das Teil ist aktuell als Funkmodul für das HM-OCCU-SDK gedacht.
Das sollte sich aber auch irgendwi in FHEM integrieren lassen.
Mal auf das nächste Journal warten. Da wird das näher vorgestellt.
gibt es offenbar schon (http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html)
Gruß Otto
Hallo,
meine Bestellung wurde heute auf Ende November verschoben, obwohl ich gestern Mittag bestellt habe. Anscheinend werden keine Module vorher ausgeliefert.
Ich gehe aber stark davon aus, dass das Modul nicht das "alte" Protokoll spricht, welches vom hmland umgesetzt wird, sondern eher das neue Protokoll des neuen LAN gateways bzw. des Kommunikationschips in der CCU2.
Wahrscheinlich müsste man da erstmal ein Fhem-Modul bauen, aber die Homegear-Leute haben das Protokoll schon implementiert, das könnte sehr helfen.
Viele Grüße
Michael
Hmm aktuell ist jetzt 1-2 Liefertage angegeben... 19€ wäre doch ein super CUL Ersatz
Hallo,
ich habe auch mal eines geordert. Ich hoffe, dass das Teil bals in Fhem integriert wird - dann kann ich einen USB Steckplatz anders nutzen (habe nur zwei).
Gruß Christoph
Hallo,
Zitat von: Bennemannc am 04 Oktober 2015, 13:51:54
ich habe auch mal eines geordert. Ich hoffe, dass das Teil bals in Fhem integriert wird - dann kann ich einen USB Steckplatz anders nutzen (habe nur zwei).
Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein fuer Fhem vollkommen neues Protokoll. Das muesste also erstmal jemand reverse-engineeren bzw. hoffen, dass es zu dem in Homegear implementierten HM-LGW-Protokoll passt und ein neues Modul fuer Fhem bauen.
Ich habe dafuer leider im Moment nicht die Zeit.
Viele Gruesse
Michael
Hallo,
ich hab das Teil auf meinem Raspi2 zusammen mit einem CUL im Einsatz.
Die Anbindung erfolgt wie an eine CCU ueber HMRPC dabei muss lediglich der rfd prozess laufen.
Wie man den aufsetzt findet ihr hier:
http://homematic-forum.de/forum/viewtopic.php?f=31&t=26879
Pairing bis jetzt habe ich erfolgreich folgende Devices gepaired:
Zwischenstecker mit Energiemessung
Rolladenaktor
Energiemesser mit Feraris Sensor
Das empfangen der Daten in FHEM funktioniert gut.
ABER bis jetzt habe ich es nicht geschafft den Rolladenaktor oder den Zwischenstecker zu schalten
Normalerweise sollte das ueber HMRPC ja so funktionieren:
set zwischenSteckerSchalt STATE true
Ich bekomme aber lediglich
-1: Failure
oder
-5: Wrong Parameter
Wenn ich anstatt FHEM aber die CCU prozesse
lighttpd und ReGaHss starte, dann kann ich mit der regulaeren Homematic Oberflaeche beide Geraete ein und ausschalten.
Hat hier jemand vielleicht Erfahrung mit HMRPC?
Gruss
rheumess
Hallo,
ich verstehe nicht ganz - Du hast eine komplette OCCU installiert ? Kann man das nicht auch etwas "einfacher" machen, ohne gleich eine CCU2 aufzusetzen. Fhem sollte doch eigentlich auch ohne das HM Geraffel direkt mit dem Modul kommunizieren können.
Gruß Christoph
Zitat von: rheumess am 18 Oktober 2015, 18:27:51
Hat hier jemand vielleicht Erfahrung mit HMRPC?
Es wäre der Grund für mich dieses Funkmodul nicht einzusetzen. Sorry aber dieses Konstrukt macht für mich gar keinen Sinn. Zu kompliziert ...
Gruß Otto
Mir waere natuerlich eine direkte Einbindung ueber ein RPI_PCB modul in FHEM auch am liebsten.
Aber das gibt es ja leider noch nicht.
Dieses Konstrukt ist auch nur zum Testen und Experimentieren.
Meine Hoffnung war ja dass ich es als Ersatz fuer meine CUL einsetzen koennte, der immerwieder die Probleme macht.
Aber bis jetzt ist das Teil weder als CCU Ersatz mit OCCU brauchbar noch als CUL oder HMLAN Ersatz.
Schade.
Gruss
Roland
Hallo,
würde mich auch interessieren was damit möglich ist.
Habe aber noch zufriedenstellend den USB-ConfigStick im Einsatz...
Vielleicht hilft das hier weiter, klingt zumindest sehr interessant:
http://homematic-forum.de/forum/viewtopic.php?f=18&t=27705
Gruß, Joachim
Hallo,
ich habe im Netz eine Software gefunden, mit den das Modul sich wie ein HM-LAN-FUNKGATEWAY verhalten soll. Das habe ich nach mehreren Tagen soweit bekommen, das diese Ausgaben im Debugmodus gezeigt werden.sync data: C
Received 8 bytes from sockFd
sync data: Y01,00,
Received 8 bytes from sockFd
sync data: Y02,00,
Received 8 bytes from sockFd
sync data: Y03,00,
Received 25 bytes from sockFd
sync data: T1DF4A63E,04,00,00000000
Received 53 bytes from sockFd
sync data: S6EAFFE6B,00,00000000,01,6EAFFE6B,998112999999000000
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
BidCos client closed connection.
Received 17 bytes from serial
0000: fd 00 0c 00 00 00 43 6f 5f 43 50 55 5f 42 4c 72 ......Co_CPU_BLr
0010: 51 Q
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
BidCos client closed connection.
Received 17 bytes from serial
0000: fd 00 0c 00 00 00 43 6f 5f 43 50 55 5f 42 4c 72 ......Co_CPU_BLr
0010: 51 Q
Client 192.168.10.43 connected to BidCos port!
Received 2 bytes from sockFd
sync data: C
Received 8 bytes from sockFd
sync data: Y01,00,
Received 8 bytes from sockFd
sync data: Y02,00,
Received 8 bytes from sockFd
sync data: Y03,00,
Received 25 bytes from sockFd
sync data: T1DF4A663,04,00,00000000
Received 53 bytes from sockFd
sync data: S6EB08E95,00,00000000,01,6EB08E95,998112999999000000
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
Received 2 bytes from sockFd
sync data: K
BidCos client closed connection.
Received 17 bytes from serial
0000: fd 00 0c 00 00 00 43 6f 5f 43 50 55 5f 42 4c 72 ......Co_CPU_BLr
0010: 51 Q
Client 192.168.10.43 connected to BidCos port!
Received 2 bytes from sockFd
sync data: C
Received 8 bytes from sockFd
sync data: Y01,00,
Received 8 bytes from sockFd
sync data: Y02,00,
Received 8 bytes from sockFd
sync data: Y03,00,
Received 25 bytes from sockFd
sync data: T1DF4A698,04,00,00000000
Received 53 bytes from sockFd
sync data: S6EB15E00,00,00000000,01,6EB15E00,9981129999990000000
Die Daten sehen auf den ersten Blick für mich nicht so schlecht aus - das Problem ist wohl 2000 ist der Datenport und 2001 ist keepAlive - vielleicht kann sich das mal jemand ansehen, der sich besser damit auskennt als ich.
Gruß Christoph
sync data: S6EB08E95,00,00000000,01,6EB08E95,998112999999000000
diese broadcast message sendet der hmlan auch, wenn er wieder bereit ist.
anscheinend disconnected/connected dein gateway ständig (3 mal).
Hallo,
jep - der connected/disconnected am laufenden Band, weil ich den üner fhem mit HMLAN angebunden habe. HMLAN hat nur einen Port - der Emulator hat zwei, einen für Daten und einen für keepAlive. Das HMLAN Modul ist aber nur auf einen Port ausgelegt. Deshalb kann ich nicht Daten bekommen und "am Leben" bleiben.
Gruß Christoph
Hallo,
das funktioniert nicht. Das ist das falsche Protokoll. Was Du da loggst sind die Daten, die Fhem schickt um den "HMLAN" zu initialisieren (auch das S... (send) kommt von Fhem), es kommt aber keine sinnvolle Antwort zurück, weil das Gerät das alte Protokoll nicht versteht.
Viele Grüße
Michael
Funkioniert nun das Module irgendwie?
Ich habe selbst das Gerät und weiß nicht wie ich es zum laufen bekomme
Korrigiert mich wenn ich falsch liege, aber laut den Bildern ist das doch nur das stink-normale CC1101 SPI-Modul mit einer minimalen Adapter-Plaine. Das Datenblatt von dem Ding ist öffentlich und auch in AskSin oder der CUL Firmware bereits implementiert. Es macht aber alleine aus Timing-Gründen sicherlich keinen Sinn das als FHEM Modul zu stricken, sinnvoller wäre es wohl so etwas wie hmland dafür zu schreiben.
An sich stelle ich mir das nicht einmal sonderlich schwer vor, allerdings habe ich leider auch weder die Zeit noch die Veranlassung das zu basteln, ich bleib beim HM-LAN ;)
Hi Marcel,
du liegst da tatsächlich falsch.
Das HM-MOD-RPI-PCB ist kein einfacher CC1101.
Da drinn werkelt zusätzlich noch ein Microkontroller der auch das AES macht. Die Kommunikation erfolgt dann über den UART und nicht über SPI.
Das Teil ist eher vergleichbar mit dem neuen HM-Lan-Interface. Also dem Teil was wie die CCU2 aussieht. Ich meine die beiden Sprechen auch das selbe Protokoll.
Gruß
Dirk
Hi Dirk,
danke, alles klar, jetzt seh ich in der Vergrößerung auch den Aufdruck HM-MOD-UART :) Überrascht mich ziemlich aber ist auf der anderen Seite auch wieder logisch wenn man die AES Keys schützen will. Mittlerweile ist die Katze natürlich eh aus dem Sack.
Ich hatte mir sogar mal die Homegear Implementation vom LAN Gateway angeschaut um das eventuell auch für FHEM zugänglich zu machen, aber am Ende nur beschlossen einfach einen HM-LAN auf Halde zu bestellen für den Fall dass das Ding eingestellt wird... einfach zu wenig Zeit für solche schöne Spielereien :(
Besten Gruß, Marcel
Zitat von: MarcelK am 09 Dezember 2015, 01:55:55
wenn man die AES Keys schützen will
Wobei das wohl hinfällig sein dürfte :)
ZitatIch hatte mir sogar mal die Homegear Implementation vom LAN Gateway angeschaut um das eventuell auch für FHEM zugänglich zu machen, aber am Ende nur beschlossen einfach einen HM-LAN auf Halde zu bestellen für den Fall dass das Ding eingestellt wird... einfach zu wenig Zeit für solche schöne Spielereien :(
Ja leider. Das hatte ich auch mal vor. Aber ich habe noch zu viele andere Baustellen.
Gruß
Dirk
Zitat von: Dirk am 09 Dezember 2015, 11:15:58
Wobei das wohl hinfällig sein dürfte :)
Ist das so? Ich dachte nur der HM-Standard Key wäre veröffentlicht. Das macht einen selbst erstellten noch nicht unsicher, oder?
Zitat von: Garagenhaus am 30 Dezember 2015, 18:02:40
Ist das so? Ich dachte nur der HM-Standard Key wäre veröffentlicht. Das macht einen selbst erstellten noch nicht unsicher, oder?
Das war damit auch gemeint. Der Standard-Key ist jetzt bekannt, es macht kaum noch Sinn ihn um jeden Preis schützen zu wollen. Selbst erstellte Keys sind nur insofern unsicherer geworden dass wenn jemand den Key-Tausch (also den "set assignHmKey") mitloggt er auch den neuen Key kennen wird. Geschieht dies nicht ist der eigentliche Betrieb genauso sicher wie vorher.
Hallo zusammen,
ich brauche einmal eure Hilfe.
Ich habe mir kürzlich bei Conrad für kleines Geld drei HomeMatic Funk-Heizkörperthermostaten bestellt ( https://www.conrad.de/de/homematic-funk-heizkoerperthermostat-hm-1402174.html ).
Nun betreibe ich in meiner Wohnung zwei Raspberry Pi, einen 'alten' Modell B und einen neueren, Modell B+ V1.2.
Ich möchte nun gerne einen Raspberry Pi für die Ansteuerung der Thermostaten verwenden und suche dafür nach einer kostengünstigen Möglichkeit.
Nach etwas Suchen bin ich auf das o.g. Funkmodul von ELV gestoßen und habe auch gesehen, dass dieses nur auf dem neuen Pi 2 Modell B funktioniert. Meine Idee war daher nun, beides bei ELV (ich habe gerade noch einen 10 Euro Gutschein) zu erwerben und dann - nachdem ich mich genug in die Materie eingelesen habe - alles per FHEM zu steuern.
Nun scheint es aber ja nicht so einfach möglich zu sein, das Funkmodul unter FHEM zu benutzen - vor allem auch, weil ich keine Zentrale/CCU2 habe und diese auch nicht kaufen möchte. Alles soll ausschließlich über den Raspberry Pi laufen.
Da ich ein Newbie in dieser Materie bin und auch keinerlei Erfahrung mit Löten usw. habe, brauche ich vor allem eine einfache Möglichkeit, alles hardwaretechnisch umzusetzen. Softwaremäßig lese ich mich in alles ein.
Könnt ihr mir sagen, was für mich eine gute, einfache und preisgünstige Möglichkeit wäre - gerne auch unter Benutzung der schon vorhandenen Raspberrys -, HomeMatic umzusetzen? Derzeit will ich damit wie gesagt nur drei Thermostate in meiner Mietwohnung steuern.
Viele Grüße und Danke für eure Hilfe
Mischa
vergiss dieses modul und besorge dir einen hm-cfg-usb-2. der funktioniert auch mit deinen vorhandenen rpi's. siehe angepinnten thread.
Vielen Dank für deinen Hinweis!
Nun habe ich hier einige Informationen gefunden, wie das Funkmodul mit einem Raspberry Pi 2 unter dem OS RaspberryMatic läuft:
http://homematic-forum.de/forum/viewtopic.php?f=56&t=26917
Natürlich ist das dann kein FHEM mehr.
Was ist denn der Vorteil von FHEM gegenüber RaspberryMatic? Der USB-Adapter ist ja grundsätzlich erst einmal doppelt so teuer, und ich frage mich halt, ob FHEM mir als Newbie und Nicht-Hardcore-Anwender von HomeMatic Vorteile bringt?
Würde mich sehr über eine Antwort hierzu freuen :-)
Viele Grüße und Danke
Mischa
Zitat von: manwald am 10 Januar 2016, 16:21:01
Was ist denn der Vorteil von FHEM gegenüber RaspberryMatic? Der USB-Adapter ist ja grundsätzlich erst einmal doppelt so teuer, und ich frage mich halt, ob FHEM mir als Newbie und Nicht-Hardcore-Anwender von HomeMatic Vorteile bringt?
Hallo Micha,
hier wird Dir wohl keiner was zu RaspberryMatic sagen können. Was FHEM tut und kann, kannst Du hier im Forum lesen.
Da musst Du für dich entscheiden...
Es gibt mittlerweile im Wiki einen kleinen Grundkurs (http://www.fhemwiki.de/wiki/Erste_Schritte_in_fhem)für FHEM, dazu brauchst Du keine Hardware. Da kannst Du dir ein kleines Bild über FHEM machen.
Zu den Kosten: die zentralen Komponenten sind die preiswerten, egal was Du kaufst. Kostenintenisv ist das was Du in Deiner Wohnung verbaust. Also die 40 Euro für den USB Adapter sind ein Witz, relativ gesehen.
Gruß Otto
ZitatDer USB-Adapter ist ja grundsätzlich erst einmal doppelt so teuer
also ich komme mit deiner variante auf 20+40=60 => 50% mehr kosten.
Okay, vielen Dank für eure Informationen und Anregungen.
Ich überlege gerade, ob es sinnvoll ist, statt das ganze System auf einem Raspberry Pi aufzubauen, doch lieber eine CCU2 zu kaufen.
Dann ist alles 'aus einem Guss' und kein 'Gefrickel'.
Macht das für mich Sinn? Wie immer vor dem Hintergrund, dass ich zwar technisch sehr interessiert und lernwillig bin, jedoch keine tiefgreifende Ahnung von Linux und Löten habe.
ZitatIch überlege gerade, ob es sinnvoll ist, statt das ganze System auf einem Raspberry Pi aufzubauen, doch lieber eine CCU2 zu kaufen.
die thermostate laufen auch alleine.
zum konfigurieren ist ein funkmodul oder die ccu ganz hilfreich, aber nicht unbedingt nötig. aber auch hierzu reicht der hmusb mit der konfigurationssoftware von eq3.
später kannst du dann in aller ruhe fhem auf deine rpi's installieren. ;)
Zitat von: manwald am 10 Januar 2016, 20:10:16
Ich überlege gerade, ob es sinnvoll ist, statt das ganze System auf einem Raspberry Pi aufzubauen, doch lieber eine CCU2 zu kaufen.
Dann ist alles 'aus einem Guss' und kein 'Gefrickel'.
Ich kann Dir eine CCU1 schenken. Da kannst Du schauen was mit der Homematic Oberfläche geht und was nicht. Später kannst Du immer noch was anderes machen.
Allerdings wird es ein nur Homematic Guss, ohne die ganzen Vorzüge von FHEM (auch ohne Linux und Löten).
Mit was laufen denn Deine Himbeeren jetzt? 8)
Gruß Otto
Der infrage kommende Pi läuft mit Raspbian, dort habe ich Pi Musicbox laufen, um ihn als WLAN-Radio zu nutzen.
Meine Überlegung ist halt
a) existierenden Raspberry Pi B+ V1.2 mit HM USB-Stick und FHEM (was wird dann aus meinem Raspbian WLAN-Radio?)
b) neu zu kaufender Raspberry Pi 2 Modell B mit HM Funkmodul von ELV und RaspberryMatic oder
c) neu zu kaufende CCU2 (wie flexibel ist dieses System?)
Würde dein Angebot sonst sehr gerne annehmen, wenn du der Meinung bist, ich kann daraus für mich interessante Erkenntnisse ziehen.
Hallo,
ich habe mit beidem schon einmal rumgemacht. Eine CCU1 steht bei einem Bekannten zur Steuerung der Außenbeleuchtung. Hier habe ich die CCU1 gewählt, weil diese noch über die Batterien eine gewisse Ausfallsicherheit bietet. Das Erstellen von Programmen finde ich auf der CCU einfacher - ist eben klicki bunt. Die Anzeige von Zuständen bwz. Werten gibt es auf der CCU nicht (oder ich habe das noch nicht gefunden). Das WebIf bei der CCU ist eben zum Einrichten gemacht und weniger zum Bedienen. Da ist fhem sehr viel besser und auch flexibler. Ich persönlich würde mit einer CCU nicht glücklich werden.
Gruß Christoph
Zitat von: Bennemannc am 11 Januar 2016, 07:36:19
ich habe mit beidem schon einmal rumgemacht. Eine CCU1 steht bei einem Bekannten zur Steuerung der Außenbeleuchtung. Hier habe ich die CCU1 gewählt, weil diese noch über die Batterien eine gewisse Ausfallsicherheit bietet. Das Erstellen von Programmen finde ich auf der CCU einfacher - ist eben klicki bunt. Die Anzeige von Zuständen bwz. Werten gibt es auf der CCU nicht (oder ich habe das noch nicht gefunden). Das WebIf bei der CCU ist eben zum Einrichten gemacht und weniger zum Bedienen. Da ist fhem sehr viel besser und auch flexibler. Ich persönlich würde mit einer CCU nicht glücklich werden.
Ich hätte es nicht besser schreiben können ...
Ich war nicht glücklich - bin es jetzt mit FHEM um so mehr!
@Micha Wenn Du Raspbian auf dem PI zum laufen gebracht hast und Musicbox einrichten konntest hast Du doch schon die nötige Linux Ahnung um FHEM einzurichten. Ich denke, die Erkenntnis von Christoph würdest Du mit meiner CCU auch bloss erlangen 8)
Ja man kann relativ schnell auf der Weboberfläche der CCU ein paar klicks machen und ja man guckt erst mal blöd auf die leere FHEM Oberfläche und sucht den klick. Aber glaube mir man braucht wenige Start Schritte bis man verstanden hat wie man FHEM zum Leben bringt.
Gruß Otto
Okay, ich werde FHEM einsetzen :)
Idee: ich verwende dafür meinen Raspberry Pi, auf dem eh schon MusicBox unter Raspbian läuft.
Ich habe mir gedacht, dass ich dafür einen CUL Stick von Busware kaufe, und zwar den C1101-USB-Lite 868Mhz kaufe: http://shop.busware.de/product_info.php/cPath/1/products_id/29?osCsid=d5696d325c8027e6a7b54925611d883e
Dieser kann unter FHEM wohl meine Homematic Funk-Heizkörperthermostate steuern als auch meine 433Mhz Funksteckdosen ansteuern.
Ist das richtig?
Und falls das so funktioniert, welche Antenne bräuchte ich dafür? Reicht auch eine einfache Drahtantenne, habe etwas von L/2, also ca. 17cm, gelesen?
Alternativ hatte ich mir ein Mediola Gateway v4 zulegen wollen.
Viele Grüße
Mischa
Hallo,
sorry für den Hinweis - aber die letzten Beiträge sind doch ein wenig OT. Gibt es etwas neues im Bezug auf die Unterstützung des Moduls durch Fhem.
Gruß Christoph
Hallo,
ich habe mich die letzten Tage mal ausgehend vom Homegear-Forum (https://forum.homegear.eu/viewtopic.php?f=16&t=351) etwas mit dem Reverse Engineering der Kommunikation mit dem HM-MOD-UART-Modul beschäftigt.
Meine Ergebnisse sind dort im Forum zu finden und den aktuellen Stand hänge ich hier mal auch noch als Datei an.
Vielleicht kann damit ja jemand was anfangen...
Gute Arbeit! Ich benötige das Modul persönlich nicht, insofern werde ich da jetzt nichts mit machen, aber ich weiß gutes Reverse-Engineering trotzdem zu schätzen :-) Nur das mit dem 4-maligen Setzen der Adressen ist ein bisschen schräg.
Hallo,
da mein HM LAN inzwischen Ärger macht möchte ich ihn ggf. ersetzen. Dazu ein paar Fragen an die Anwender des RPi Moduls:
- Funktioniert auch der Homematic Komponenten Konfigurator (hm_config.exe) mit diesem Modul (am RPi 3)?
- Kann man damit eine Keymatic ansteuern, auch wenn FHEM auf dem Pi läuft?
- Ist die Reichweite ohne Antennenmodifikation einem HM LAN vergleichbar?
Danke!
Zu den ersten beiden Punkten kann ich nix sagen, aber zum Thema Reichweite.
Ich habe einen HMLAN und ein HM-MOD-RPI-PCB. Der HMLAN ist im OG, der Pi im Keller. Ich habe beide IOs einer VCCU zugeordnet. Es werden viele Geräte die im EG sind vom Pi-Modul bedient, da darüber der RSSI besser ist. Teilweise sogar einige Komponenten im OG, was mich sehr überrascht hat.
Also ich würde sagen die Reichweite ist vergleichbar, bei mir sogar besser.
Hallo Mathias R,
zum hm_config.exe kann ich auch nix sagen.
Edit:
Du meinst das Windows Programm "Launch HomeMatic-Komponenten konfigurieren"? Wie sollte das funktionieren? Das ist für HMLAN und HMUSB, dieser muss zu dem Zweck dann am Windows Rechner stecken.
Warum sollte der Keymatic nicht ansteuerbar sein? Dazu braucht es AES und das funktioniert.
Wirklich was sagen kann ich zur Reichweite, ich habe einen HMLAN mit modifizierter Antenne (http://heinz-otto.blogspot.de/2015/07/pimp-my-hmlan.html)und das PI Modul mit original Antenne ist bei mir bei einigen Situationen besser, in keinem Fall schlechter.
Ich würde also behaupten, die Reichweite ohne Antennenmodifikation ist etwas besser als die des HMLAN.
Gruß Otto
Zitat von: Otto123 am 21 September 2016, 10:27:52
Ich würde also behaupten, die Reichweite ohne Antennenmodifikation ist etwas besser als die des HMLAN.
Den Eindruck kann ich teilen.
Seit Inbetriebnahme meines HM-MOD-UART-WIFI übernimmt dieser größtenteils die Steuerung.
Laut VCCU sind die RSSI-Werte beim HM-MOD-UART-WIFI überall besser als vom HM-CFG-LAN.
Beide haben bei mir die originalen Antennen ohne Modifikation(en).
Gruß
Dan
Zitat von: DeeSPe am 21 September 2016, 10:47:49
Laut VCCU sind die RSSI-Werte beim HM-MOD-UART-WIFI überall besser als vom HM-CFG-LAN.
Genau ich habe mal meine VCCU gefragt, die meint es ist relativ ausgeglichen:
devices using VCCU
current IO / preferred
HMLAN1 / --- HM_33980B
HMLAN1 / --- HM_4BDA72
HMLAN1 / --- HzgAkDecke
HMLAN1 / --- HzgAkSchraege
HMLAN1 / --- HzgAzGaube
HMLAN1 / --- HzgAzSchraege
HMLAN1 / --- HzgAzSpitze
HMLAN1 / --- HzgGzDecke
HMLAN1 / --- HzgGzGaube
HMLAN1 / --- HzgGzSchraege
HMLAN1 / --- LichtGaDecke
HMLAN1 / --- LichtKuL
HMLAN1 / --- LichtKuR
HMLAN1 / --- PSD3
HMLAN1 / --- RC41
HMLAN1 / --- RC42
HMLAN1 / --- RC61
HMLAN1 / --- RolloAK
HMLAN1 / --- RolloBDu
HMLAN1 / --- RolloWZR
HMLAN1 / --- SD1
HMLAN1 / --- SD2
HMLAN1 / --- SD3
HMLAN1 / --- SD4
HMLAN1 / --- Schalter3
HMLAN1 / --- SensorAK
HMLAN1 / --- SensorAussen
HMLAN1 / --- SensorGZ
HMLAN1 / --- SensorKE
HMLAN1 / --- SensorR2
HMLAN1 / --- SensorWG
HMLAN1 / --- Taster4_01
HMLAN1 / --- TeamDev1
HMLAN1 / --- VCCU
HMUART1 / --- FB12
HMUART1 / --- FensterBadOg
HMUART1 / --- FensterWZR
HMUART1 / --- HM_4C26A7
HMUART1 / --- LichtBWa
HMUART1 / --- LichtSz
HMUART1 / --- LichtWzLO
HMUART1 / --- LichtWzLU
HMUART1 / --- LichtWzR
HMUART1 / --- PIR1
HMUART1 / --- PIRFront
HMUART1 / --- PIRWg
HMUART1 / --- PSD1
HMUART1 / --- PSD2
HMUART1 / --- RC62
HMUART1 / --- RC81
HMUART1 / --- RmAZ
HMUART1 / --- RmFlur
HMUART1 / --- RmSZ
HMUART1 / --- RolloAZL
HMUART1 / --- RolloAZLL
HMUART1 / --- RolloAZR
HMUART1 / --- RolloBWa
HMUART1 / --- RolloGZR
HMUART1 / --- RolloKUL
HMUART1 / --- RolloKUR
HMUART1 / --- RolloSZ
HMUART1 / --- RolloWZL
HMUART1 / --- SW01
HMUART1 / --- SW1
HMUART1 / --- SW2
HMUART1 / --- SW3
HMUART1 / --- SW81
HMUART1 / --- SensorR1
HMUART1 / --- TasterDIS
HMUART1 / HMUART1 RolloGZL
Gruß Otto
Ich glaube, mit meiner Frage bin ich aktuell hier besser aufgehoben...
Zitat
Bisher habe ich einen Cubietruck (CT) mit FHEM, an dem als IO-Device das alte LAN-Gateway und ein HM-CFG-USB-2 angeschlossen sind (und zum Testen das neue LAN-Gateway).
Ich spiele mit dem Gedanken, einen RPI mit dem HomeMatic Komplettbausatz Funkmodul für Raspberry Pi aufzusetzen als weiteres IO-Device. Die Anbindung an's Netz müsste sogar über WLAN erfolgen, da ich am geplanten Einsatzort keinen LAN-Anschluss habe.
Auf dem CT verwende ich eine vccu. An diese möchte ich das zusätzliche IO-Device anbinden. Geht das dann überhaupt? Die Vorteile der vccu möchte ich nicht missen.
Wenn ja, müsste das doch über WLAN genauso möglich sein, da in der Definition zum HMUARTLGW ja nur die IP eingetragen wird (zumindest beim LAN-Adapter).
Mir ist aber nicht klar, wie der RPI softwareseitig eingerichtet werden muss. Benötige ich da auch ein FHEM drauf. Geht das dann nur über eine Kopplung fhem2fhem. Oder kann ich den FHEM-Part auf dem RPI auslassen?
Aus euren Antworten habe ich jetzt schon mal herausgelesen, dass die Anbindung an eine vccu auf einem anderen Rechner möglich ist. Wie wird das aber realisiert? Nur die IP des anderen Rechners angeben oder muss noch eine fhem2fhem-Kommunikation aufgebaut werden? Oder wird auf dem RPI gar kein FHEM benötigt? Irgendwie fehlt mir da noch das Verständnis.
Danke für Infos
Holger
Hallo Holger,
ne hier bist Du auch nicht besser aufgehoben. Der Thread fing an, da gab es das Modul von mgernoth noch gar nicht.
Zitatdass die Anbindung an eine vccu auf einem anderen Rechner möglich ist.
Wo hast Du das hier gelesen? Hier geht es um die VCCU und mehrere IOs, von Remote Anbindung des Pi ist hier nicht die Rede.
Ob das geht, wie das geht ... Derzeit geht es wahrscheinlich nicht. mgernoth will sein Modul noch Richtung hmland entwickeln, aber ob und wann?
Derzeit arbeiten alle intensiv an einer autarken WLAN Variante, aber das findest Du im Thread wo Du schon warst, bzw. in dem Link der dort auch existiert https://forum.fhem.de/index.php/topic,56606.0.html
Ich bin mir einigermaßen sicher, dass was Du willst geht derzeit nicht so einfach. Sonst hätte ich oder jemand anderes schon geantwortet.
Gruß Otto
Sorry, dann habe ich das falsch verstanden (Wunschlesen war wohl aktiviert ;) )
Um die VCCU inkl. Anbindung mehrerer IOs geht es mir ja auch - insoweit sind wir schon beieinander. Allerdings (Wunsch) über einen anderen Rechner.
Eine Platine für HM-MOD-UART mit ESP8266 ist mittlerweile auch schon bestellt - das wird aber sicher noch 'ne Weile dauern. Ich dachte, kurzfristig mit einem RPI und dem HMUART schon weiterkommen zu können.
Trotzdem danke - dann kenne ich wenigstens den aktuellen Stand
LG
Holger
Suchst du evtl. sowas:
https://forum.fhem.de/index.php/topic,54511.330/wap2.html (https://forum.fhem.de/index.php/topic,54511.330/wap2.html)
Danke, das war ein Schubser in die richtige Richtung.
Ich habe mir jetzt das Platinchen einfach mal bestellt und werde dann mal experimentieren.
LG
Holger
Zitat von: Omega am 21 September 2016, 23:26:12
Sorry, dann habe ich das falsch verstanden (Wunschlesen war wohl aktiviert ;) )
Ja, schon verrückt was der Kopf manchmal mit uns macht 8)
Geht mir auch oft so, obwohl ich mittlerweile viel kritischer bin beim lesen.
Ich hatte mich selbst auch probiert mit socat usw. aber ohne Erfolg. Ich habe irgendwann einfach das Modul auf den produktiven PI gesteckt und jetzt werkelt die VCCU mit HMLAN und HMUART prima.
Über FHEM2FHEM habe ich auch erfolgreich probiert, aber das ist eben mühsam. Hat nicht von redundanten IO sondern ist eher für spezielle Aufgabe an einem abgesetzen Standort.
Gruß Otto
Erstmal vielen Dank für die ausführlichen Berichte zur Reichweite.
Die originale Windows-Software benutze ich um Komponenten direkt zu verbinden (z.B. Keymatic mit Funkschlüssel) oder zu konfigurieren (z.B. max. Verweildauer im Zustand ein beim Lichtschalter).
Könnte man dafür z.B. den Pi über einen Port als HM LAN ansprechen oder gibt es eine andere Möglichkeit die Komponenten zu konfigurieren und direkt zu verknüpfen?
Danke!
Gruß, Mathias
Zitat von: Mathias R am 24 September 2016, 11:18:39
Die originale Windows-Software benutze ich um Komponenten direkt zu verbinden (z.B. Keymatic mit Funkschlüssel) oder zu konfigurieren (z.B. max. Verweildauer im Zustand ein beim Lichtschalter).
Könnte man dafür z.B. den Pi über einen Port als HM LAN ansprechen oder gibt es eine andere Möglichkeit die Komponenten zu konfigurieren und direkt zu verknüpfen?
Hallo Mathias,
Also da sage ich mal mit ziemliches Sicherheit nein. Es ist ein anderes Funkmodul als der HMLAN und die Windows Software weiß nichts davon.
Es kann sein das die Windows Software von HM auch das neue HM Lan Gateway unterstützt. Das könntest Du prüfen und dann dieses einsetzen.
Gruß Otto
Um das ganze etwas kompakter zu gestalten habe ich mir jetzt auch mal das Modul bestellt und es gerade eingebaut.
Vorher natürlich nach folgender Anleitung alles vorbereitet: http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Vorbereitung_serielle_Schnittstelle_unter_Jessie (http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Vorbereitung_serielle_Schnittstelle_unter_Jessie)
Die Ausgabe unter Jessie ist bei mir wie im Wiki beschrieben.
Jetzt habe ich nur den Eintrag vom Wiki:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx
Umgeändert in:
define HMLAN1 HMUARTLGW /dev/ttyAMA0
attr HMLAN1 hmId xxxxxx
damit ich nicht alle Devices anpacken muß.
Den AES Code habe ich auch vom HMLAN1 übernommen und diesen ausdokumentiert.
Allerdings wird dann nichts gefunden.
Muß ich jetzt ALLE Geräte neu anlernen oder wo ist mein denk Fehler?
Hi,
also das mit HMLAN1 war quatsch, denke ich ...
Du hast die gleiche HMID genommen?
Du hattest einen HMLAN und der hieß HMLAN1?
Ich hätte alles auf VCCU umgestellt.
Der VCCU beide IOs bekannt gemacht.
Dann hätten beide IOs ihren Dienst getan, man hätte einen abschalten können.
Gruß Otto
Hallo zusammen,
ich hänge mich als Neuling einmal direkt an diesen Thread in der Hoffnung, dass meine Frage (und die dazugehörenden Überlegungen) hier gut reinpassen.
Aktuell hängt an meiner Himbeere ein HMLAN, eine Kombination die bisher hier mit FHEM wunderbar läuft. Eher zufällig bin ich jetzt aber auf den HM-MOD-RPI-PCB Bausatz aufmerksam geworden, und frage mich, ob es nicht sinnvoll sein könnte, gegen den guten Grundsatz "never change a running system" zu verstoßen.
Für das Funkmodul spricht meiner Meinung nach, ...
- dass ich mir eine Komponente mit eigenem Netzstecker sparen kann.
- dass der LAN-Port am RasPi wieder frei wird (um ihn z.B. direkt an die Fritzbox zu hängen, wodurch ich kein WLAN mehr bräuchte und wieder einen freien USB-Port hätte).
- die zumindest gleichwertige (wenn nicht sogar bessere) Verbindungsqualität (siehe Vorposts zum Thema)
Als Nachteil sehe ich bisher nur, dass ich mein RaspPi-Gehäuse dann wohl nicht mehr brauchen kann. ;) Oder übersehe ich etwas wichtiges?
Vorab schon einmal vielen Dank! :D
Hallo AndreAC,
warum Du nicht alle Komponenten am Netzwerkswitch betreibst, erschließt sich mir nicht.
Zu Deinem Problem mit dem Gehäuse: normalerweise wird das Modul ja zum zusammenlöten ausgeliefert (es soll andere Fälle geben). Du kannst das Modul "verkehrt" zusammenlöten, dann nimmt es viel weniger Höhe ein und passt meist in niedrige Gehäuse. Das hängt aber sehr von Deinem Gehäuse ab.
Gruß Otto
Wieso hast du den HMLAN am LAN-Port des Raspi? Meiner hängt an der Fritte und die Himbeere ist seit Monaten per WLAN gekoppelt, der LAN bleibt frei.
Ein neues Gehäuse brauchst Du nicht unbedingt - das Modul passt auch in mein Gehäuse noch mit hinein. Ich habe nur für die Antenne ein Loch gebohrt und diese nach außen geführt.
Mein HMLAN und das Raspimodul haben je nach Gerät unterschiedliche RSSI (Raspi mittig im OG, HMLAN an einer Außenwand im EG). Mit der vccu nutze ich "best of both worlds" - fällt ein Interface aus, läuft alles nahtlos über das andere.
Ich kann Dir nur zuraten. Besorge das Modul, richte es ein und nutze es über eine vccu gemeinsam mit dem HMLAN. Dann kannst Du on-the-fly das HMLAN temporär lahmlegen und schauen ob alles weiterhin wie gewünscht funktioniert - der Rückweg wäre dann einfach. Aber die 20 Euro sind gut angelegt - Du hast nämlich dann auch eine sehr bequeme und zuverlässige Möglichkeit für Firmwareupdates.
Ursprünglich hatte ich einmal vor, das HMLAN dem FHEM zu lassen und auf dem Raspi parallel eine CCU mit dem HMUART zu installieren. Als Funktest hatte ich es zunächst FHEM zugeordnet, aber es macht sich so gut dort, dass ich vielleicht auch eher das HMLAN in den Ruhestand schicke...
Ich komme nicht wirklich weiter mit dem Modul. :(
Angelegt habe ich jetzt beide Deviced + VCCU folgendermassen:
define HMLAN1 HMLAN 192.168.1.22:1000
attr HMLAN1 hmId 123456
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room hidden
define HMPCB HMUARTLGW /dev/ttyAMA0
attr HMPCB hmId abcdef
define VCCU CUL_HM 123456
attr VCCU IOList HMLAN1, HMPCB
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Der LAN Adapter lief ja schon immer, da ist alles sauber.
Die Platine meldet mir jetzt:
nternals
CFGFN
CNT 0
DEF /dev/ttyAMA0
DevState 0
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 44
LastOpen 1481111674.35417
NAME HMPCB
NR 426
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Readings
D-type HM-MOD-UART 2016-12-07 12:50:34
cond disconnected 2016-12-07 12:54:34
loadLvl suspended 2016-12-07 12:50:34
state opened 2016-12-07 12:54:34
Also eingerichtet müsste die Schnittstelle richtig sein.
Und die VCCU meldet:
STATE HMLAN1:ok, HMPCB:unknown
Hi Christian72D,
Dies folgende Zeile ist eigentlich sinnlos und sicher verkehrt, aber eventuell egal wegen der VCCU
Zitatattr HMPCB hmId abcdef
Die folgende Zeil ist falsch:
Zitat
attr VCCU IOList HMLAN1, HMPCB
muss so aussehen:
attr VCCU IOList HMLAN1,HMPCB
Ich kann aber nicht erkennen ob das RPI Modul richtig läuft. Ist der Status stabil connected?
Gruß Otto
Zitat von: Otto123 am 07 Dezember 2016, 13:48:56
Hi Christian72D,
Dies folgende Zeile ist eigentlich sinnlos und sicher verkehrt, aber eventuell egal wegen der VCCU
Ich kann aber nicht erkennen ob das RPI Modul richtig läuft. Ist der Status stabil connected?
OK, ich dachte JEDES HM Device benötigt eine HMId. Mein Fehler.
Wie auch der mit dem Leerzeichen. :D
Woran sehe ich das denn genau? JETZT steht zumindest in der IOList nicht mehr "unknown" sondern "init".
Zitat von: Christian72D am 08 Dezember 2016, 08:58:07
OK, ich dachte JEDES HM Device benötigt eine HMId. Mein Fehler.
Woran sehe ich das denn genau? JETZT steht zumindest in der IOList nicht mehr "unknown" sondern "init".
Moin,
Deine Annahme mit der hmId ist richtig. Aber normalerweise brauchen alle IOs die dieselbe. Die VCCU setzt diese aber sobald die IOs untergeordnet werden.
Du meinst im STATE der VCCU steht jetzt hinter HMPCB init? Das ist zwar besser als unknown aber noch nicht wirklich gut. Der HMPCB arbeitet also noch nicht. Eigentlich muss da ok stehen.
Du musst die Einrichtung des RPI MOduls nochmal überprüfen. Hast Du im Log irgendwelche Einträge? Wechselt der Status des Moduls?
Gruß Otto
OK, jetzt sind dann alle DREI hmIds gleich, danke.
Im Log finde ich folgendes:
2016.12.08 12:51:48 3: Setting HMPCB serial parameters to 115200,8,N,1
2016.12.08 12:51:48 1: /dev/ttyAMA0 reappeared (HMPCB)
Device is not available.
2016.12.08 12:51:52 1: HMUARTLGW HMPCB did not respond for the 1. time, resending
Device is not available.
2016.12.08 12:51:55 1: HMUARTLGW HMPCB did not respond for the 2. time, resending
2016.12.08 12:51:58 1: HMUARTLGW HMPCB did not respond for the 3. time, resending
2016.12.08 12:52:00 3: HMPCB device closed
2016.12.08 12:52:00 1: HMPCB is against deletion (VCCU), continuing with rereadcfg anyway
Mit der Einrichtung der Schnittstelle am RasPi bin ich nach Anleitung vorgegangen. Da kam keine Fehlermeldung.
Hi,
das klingt mir wie Modul arbeitet gar nicht! Beim Löten was schief gelaufen?
Ich hatte erst vor kurzem einen ähnlichen Fall. Ich glaube er hatte ne Lötbrücke zwischen zwei Pins. Wenn Du willst mach ein Foto von Lötstellen und ich schau drauf :)
Oder serielle Schnittstelle durch anderes Modul belegt?
Gruß Otto
Ich denke schon daß das richtig gelötet ist, aber wirf gerne mal einen Blick drauf:
christian72d.mine.nu/temp/hm/2016-12-8 19-0-9.jpg (http://christian72d.mine.nu/temp/hm/2016-12-8%2019-0-9.jpg)
christian72d.mine.nu/temp/hm/2016-12-8 18-59-22.jpg (http://christian72d.mine.nu/temp/hm/2016-12-8%2018-59-22.jpg)
Du hast die Buchse auf die falsche Seite gelötet! So geht das nicht. :-X
siehe hier http://www.fhemwiki.de/wiki/Datei:HM-MOD-RPI-PCB.jpg
Gruß Otto
Oh Mann wie peinlich... :o
Zitat von: Christian72D am 09 Dezember 2016, 06:25:06
Oh Mann wie peinlich... :o
Vor allem hast Du auch die Beine verlötet, die nicht gebraucht werden ;D
Wie bekommst Du die jetzt wieder ab. Früher habe ich da mit passenden Kanülen gearbeitet. Aber da geht bestimmt eng zu. Entlötpumpe kannst Du auch versuchen.
Viel Erfolg
Otto
Ja, hat geklappt, war echt eine fiese Arbeit heute morgen gewesen, aber gut wenn man auf der Arbeit das nötige Werkzeug hat.
UND es läuft auf Anhieb...
Komisch, kaum macht man es richtig klappt auch alles. :D
DANKE
Entlötpumpe geht eigentlich super für sowas. Da hab ich schon 40polige Stecker mit ausgelötet :D
Dauert halt, aber geht gut.
Zitat von: Christian72D am 12 Dezember 2016, 16:21:42
Ja, hat geklappt, war echt eine fiese Arbeit heute morgen gewesen, aber gut wenn man auf der Arbeit das nötige Werkzeug hat.
UND es läuft auf Anhieb...
Komisch, kaum macht man es richtig klappt auch alles. :D
DANKE
Super, freut mich!
Gruß Otto
Guten Abend die Herren,
ich hab endlich meinen HM-MOD-RPI-PCB erhalten. Zusammenlöten und einbinden soweit kein Problem.
Ich habe allerdings schon einen Busware 433CUL am laufen und dieser funktioniert nun nicht mehr. Ich nehme an dass dies mit dem systemctl disable serial-getty@ttyAMA0.service zusammen hängt, da dieser ja über diese "Schnittstelle" eingebunden war.
Gibt es eine Möglichkeit diesen wieder einzubinden?
MfG Ulf
???
Die CULs laufen doch über USB. ttyAMA0 ist die Raspi-bordeigene Serial auf der Steckerleiste. Der von Dir genannte Befehl soll dafür sorgen, dass das Betriebssystem die Schnittstelle exklusiv FHEM überlasst, sozusagen. Das hat aber alles nicht die Bohne mit USB zu tun.
Guck mal die Konfig für Deinen CUL genau an, poste mal die DEF.
BTW: es ist sowieso besser, alle USB-Geräte per serial/by-id anzubinden: meine DEF sieht so aus:
define CUL433 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH02Z8QS-if00-port0@38400 2014\
Zitat von: Vista am 17 Dezember 2016, 17:54:56
Guten Abend die Herren,
ich hab endlich meinen HM-MOD-RPI-PCB erhalten. Zusammenlöten und einbinden soweit kein Problem.
Ich habe allerdings schon einen Busware 433CUL am laufen und dieser funktioniert nun nicht mehr. Ich nehme an dass dies mit dem systemctl disable serial-getty@ttyAMA0.service zusammen hängt, da dieser ja über diese "Schnittstelle" eingebunden war.
Gibt es eine Möglichkeit diesen wieder einzubinden?
MfG Ulf
Hallo Ulf,
es gibt hier auch Damen ;)
Wenn Du meinst, dass der CUL über die AMA0 eingebunden war, das ist aber keine CUL der auf dem GPIO hängt? :-\
Gruß Otto
Guten Morgen die Herren und natürlich auch die werten Damen,
mein Fehler, natürlich sind hier auch Damen.
Nochmal zur Zusammenfassung meines Problems:
Ich habe eine Raspi2 mit Debian 8.0 und Fhem (aktuell) am laufen.
Bisher hatte ich einen:
Busware CUL 433 (Link (http://shop.busware.de/product_info.php/cPath/1/products_id/44))
und einen 868 nanoCUL (Link (https://wiki.fhem.de/wiki/Selbstbau_CUL))
Diese waren wie folgt eingebunden:
Busware CUL über die Fhem vorgabe nach usb scann usw.. -> define CUL_0 CUL /dev/ttyACM0@38400 1034
der nanoCUL -> define nanoCUL CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505KYFR-if00-port0@38400 0000
jetzt das Problem seit gestern besitze ich noch den HM.... und nach dem dieser Wunderbar funktioniert ist mein BuswareCUL allerdings immer disconnected.
Wo bekomme ich jetzt die def für die einbindung by serial für den 433CUL her??
MfG Ulf
PS: Muss los Frühstücken, Frau ruft schon ;)
ACM0 ist nicht AMA0 ... Schnittstellenkollision ist da also nicht zu erwarten.
Guck mal in die Verzeichnisstruktur /dev/serial/by-id (Kommandozeile per putty reicht), im Idealfall sind dort neben Deinem Nano noch zwei Einträge, von denen einer das HMUART sein müsste, der verbleibende dann dein anderer CUL. Ansonsten gibts auch Kommandos zum Auflisten, müsste ich aber erst raussuchen.
via Tapatalk
Hallo Vista,
mach doch mal bitte folgendes und poste die Ausgaben:
ls -l /dev/ttyA*
ls -l /dev/serial/by-id
ls -l /dev/ttyAMA0
ls -l /dev/ttyACM0
systemctl status serial-getty@ttyAMA0
systemctl status serial-getty@ttyACM0
Gruß Otto
Super vielen dank für die schnelle hilfe.
Bin geradevkurz angebunden. Heute war cer CUL unter serials by-id aufgelistet und konnte eingebunden werden.
Hatte nochmals alles neu gesteckt und gebootet. Gestern war er dort nicht aufgelistet. Jetzt scheind alles wieder zu funktioniern .danke
Hallo, ich versuche mich auch gerade an dem Funkmodul und habe dazu extra ein Testsystem aufgesetzt. Ich versuche das ganze auf einem Banana PI mit Jessie. Ich konnte das Modul in FHEM auch anlegen und dort auch die FW aktualisieren, jedoch bekommen ich keine Geräte zu sehen nur "Unknown code".
Internals:
AssignedPeerCnt 0
CNT 46
DEF /dev/ttyS2
DEVCNT 149
DevState 99
DevType UART
DeviceName /dev/ttyS2@115200
FD 11
LastOpen 1482354707.24184
NAME myHmUART
NR 20
PARTIAL
RAWMSG 05000018088670194C2B00000000B92E
RSSI -24
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 1
msgLoadHistory 0/0/0/0/0/0/0/0/0/1/0/0
msgLoadHistoryAbs 1/1/1/1/1/1/1/1/1/1/0/0/0
owner 000006
Helper:
CreditTimer 31
FW 66561
Initialized 1
Ackpending:
LastSendLen:
3
3
Log:
IDs:
Roundtrip:
Delay 0.0031440258026123
Loadlvl:
lastHistory 1482363710.00236
Peers:
Readings:
2016-12-21 22:11:49 D-HMIdAssigned 000006
2016-12-21 22:11:49 D-HMIdOriginal 4C3D27
2016-12-21 22:11:49 D-firmware 1.4.1
2016-12-21 22:11:49 D-serialNr NEQ0605143
2016-12-21 22:11:47 D-type HM-MOD-UART
2016-12-21 22:11:50 cond ok
2016-12-22 17:31:54 load 1
2016-12-21 22:11:50 loadLvl low
2016-12-21 22:11:47 state opened
Attributes:
hmId 000006
hier mal ein Auszuge aus dem LOG
2016.12.21 22:11:47 3: Opening myHmUART device /dev/ttyS2
2016.12.21 22:11:47 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 22:11:47 3: myHmUART device opened
2016.12.21 22:11:47 1: Including ./log/fhem.save
2016.12.21 22:11:47 1: usb create starting
2016.12.21 22:11:48 1: usb create end
2016.12.21 22:11:48 2: SecurityCheck: WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.12.21 22:11:48 0: Featurelevel: 5.7
2016.12.21 22:11:48 0: Server started with 11 defined entities (fhem.pl:12804/2016-12-17 perl:5.020002 os:linux user:fhem pid:1356)
2016.12.22 17:26:57 3: myHmUART: Unknown code A0B05A258194C2B194F070000::-24:myHmUART, help me!
2016.12.22 17:26:57 3: myHmUART: Unknown code A0E058202194F07194C2B0101000035::-43:myHmUART, help me!
2016.12.22 17:26:57 3: myHmUART: Unknown code A0BA3A2581979B6194F240000::-58:myHmUART, help me!
2016.12.22 17:26:57 3: myHmUART: Unknown code A0EA38202194F241979B60101000034::-49:myHmUART, help me!
2016.12.22 17:27:03 3: myHmUART: Unknown code A0DA684102C274100000206012200::-31:myHmUART, help me!
2016.12.22 17:27:05 3: myHmUART: Unknown code A0BB7A25819E210194E680000::-63:myHmUART, help me!
2016.12.22 17:27:05 3: myHmUART: Unknown code A0EB78202194E6819E2100101000038::-68:myHmUART, help me!
2016.12.22 17:27:23 3: myHmUART: Unknown code A0C3D867019795900000000B735::-55:myHmUART, help me!
2016.12.22 17:27:35 3: myHmUART: Unknown code A0CFE8670194C0100000000B72F::-38:myHmUART, help me!
2016.12.22 17:27:43 3: myHmUART: Unknown code A0B3DA258197959194F610011::-58:myHmUART, help me!
2016.12.22 17:27:43 3: myHmUART: Unknown code A0E3D8202194F6119795901010C0039::-50:myHmUART, help me!
2016.12.22 17:27:51 3: myHmUART: Unknown code A0CB086701979F400000000AB39::-58:myHmUART, help me!
Grüße
cerberus
@Cerberus:
sieht doch gut aus!?
Das Modul empfängt...
...daher die HelpMe-Meldungen.
Modul empfängt und fhem kann die Nachrichten nicht zuordnen -> daher die Einträge...
Hast du autocreate aktiv?
Du sagst Testsystem: hoffentlich eigene/andere HMID!? Sonst geht (bald) einiges durcheinander!
Die Geräte sind ja wahrscheinlich am "Hauptsystem" angelernt!?
Geräte können immer nur mit einer Zentrale verbunden werden...
...also entweder eins oder zwei oder drei ablernen/resetten und dann am Testsystem anlernen...
...oder halt auch für's Testsystem Testgeräte besorgen...
Gruß, Joachim
Danke Joachim, ich verstehe. Ich dachte FHEM erkennt die Geräte auch ohne anlernen. Ich habe eine andere HMID als die vom produktiven System. Ich habe noch einen neuen Heizungsregler, den kann ich ja mal anlernen.
Grüße
cerberus
Super, funktioniert.
rssi done: Device receive from last avg min_max count HM_502D96 myHmUART HM_502D96 -21.0 -20.9 -21.0< -19.0 39
Wenn autocreate an ist und du das Gerät in den Anlernmodus bringst (wird allerdings einen Fehler geben, da das Gerät ja bereits an eine andere Zentrale angelernt ist) dann wird es vermutlich tatsächlich in fhem auf dem Testsystem angelegt.
Du kannst dann wohl auch den Status mitlesen...
Aber halt nicht steuern.
Und du bekommst wahrscheinlich "Sabotage-Messages" im Hauptsystem...
Daher ist es wohl für einen Test besser ein neues Testgerät zu nehmen...
Wenn dich die Logeinträge stören (die werden dann auch bei deinem Hauptsystem kommen, wenn du das Testgerät am Testsystem anlernst), dann solltest du eine vccu anlegen.
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)
Schadet generell nicht und vereinfacht auch einen späteren Tausch eines IODev bzw. die Erweiterung um ein weiteres IODev...
Ich würde auch autocreate immer nur dann an dem System aktivieren, wo ich das (neue) Gerät auch anlernen will und ansonsten "disable 1" setzen...
So mache ich das mit meinem Haupt- und Testsystem...
Gruß, Joachim
Hallo zusammen,
ich habe mittlerweile sehr viele Sensoren und Aktoren - und manchmal merke ich, dass ein einzelnes Modul an seine Grenzen hinsichtlich der Sendelast (1%) und der Queue gerät - Insbesondere wenn beim Verlassen der Wohnung viele befehle abgesetzt werden müssen.
Daher möchte ich ein zweites Modul irgendwie anbinden. Die Frage ist nur: Wie? Kann man die Module auf einem Pi stacken? Oder ist es sinnvoller das über die im Wiki beschriebene Methode auf einen anderen Pi auszulagern?
LG, Jan
Hallo Jan,
die Module verwenden die UART vom Raspi, davon gibt es erstmal nur eine. Stacken ist also nicht. Auch funktechnisch wäre das nicht gut.
Du kannst entweder auf einen zweiten Raspi Remote (falls einer rumliegt) oder per Wemos D1 über Wlan.
Sicher gibt es noch viele andere Varianten, aber das sind die beiden die ich relativ simpel finde.
Was ist viele? Also wieviele HM Komponenten hast Du? Vielleicht ist auch nur das Eine oder Andere unglücklich gelöst?
Gruß Otto
Hi hi,
sorry dass ich das noch mal hoch hole... Aber ich habe eine Verständnisfrage:
Ich habe derzeit einen Raspi 1 mit dem Funkmodul mit integriertem Display von busware. Ich möchte jetzt auf einen Raspi 3 mit dem PCB wechseln. Muss ich jetzt wirklich alles neu anlernen ? Ich habe teilweise Aktoren unter Putz verbaut und müsste dafür extra nen Schrank abhängen... Einfach Config einspielen und gleiche HM ID reicht nicht ?!
Danke :)
Chris
Zitat von: MegaData am 07 Januar 2017, 17:35:59
Ich möchte jetzt auf einen Raspi 3 mit dem PCB wechseln. Muss ich jetzt wirklich alles neu anlernen ? ... Einfach Config einspielen und gleiche HM ID reicht nicht ?!
Natürlich reicht die Config mit der gleichen hmID. Nix neu anlernen. Die "Telefonnummer" der Zentrale ändert sich ja dann nicht, wie sollen die Geräte den Unterschied merken?
Nur parallel betreiben darfst Du beide Zentralen nicht, sonst hagelt es sabotageAttacks. Allerdings ohne bleibende Schäden.
Wie sieht es mit der Sende/Empfangsleistung aus, hat da jemand schon Erfahrung ? Da hängt ja nun keine Antenne sondern nur ein Stück Draht dran... Das ist annähernd gleich ?
Du wirst positiv überrascht sein ...
Hi Chris,
ich weiß nicht wie umfangreich Deine config ist, aber Du mehrere Varianten "umzusteigen"
Wenn Du noch etwas Geduld hast gibt es hier (http://heinz-otto.blogspot.de/)in Kürze einen Artikel über meinen Umstieg von einen Pi auf den anderen.
Neben der kompletten Übernahme der config, kannst Du auch Blockweise vorgehen. Ansätze dazu habe ich hier mit eingebaut:
http://heinz-otto.blogspot.de/2016/09/fhem-in-wenigen-schritten.html
http://heinz-otto.blogspot.de/2016/01/anwesenheitserkennung.html
Gruß Otto
Hallol,
ich baue mir gerade einen neuen Fhem Server mit Raspberry Pi2 und dem Funkmodul auf.
Im Log kommt aber eine Fehlermeldung und der stat des Funkmoduls steht nur auf opened.
2017.01.11 09:35:01 1: Including fhem.cfg
2017.01.11 09:35:01 3: telnetPort: port 7072 opened
2017.01.11 09:35:02 3: WEB: port 8083 opened
2017.01.11 09:35:02 3: WEBphone: port 8084 opened
2017.01.11 09:35:02 3: WEBtablet: port 8085 opened
2017.01.11 09:35:02 2: eventTypes: loaded 15 events from ./log/eventTypes.txt
2017.01.11 09:35:02 3: Opening myHmUART device /dev/ttyAMA0
2017.01.11 09:35:02 3: Setting myHmUART serial parameters to 115200,8,N,1
2017.01.11 09:35:02 3: myHmUART device opened
2017.01.11 09:35:02 1: Including ./log/fhem.save
2017.01.11 09:35:02 1: usb create starting
2017.01.11 09:35:03 1: usb create end
2017.01.11 09:35:03 2: SecurityCheck: WEB,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.01.11 09:35:03 0: Featurelevel: 5.7
2017.01.11 09:35:03 0: Server started with 11 defined entities (fhem.pl:12966/2017-01-05 perl:5.020002 os:linux user:fhem pid:550)
2017.01.11 09:59:58 1: HMUARTLGW myHmUART unexpected info about Co_CPU_BL received (module crashed?), reopening
2017.01.11 09:59:58 3: myHmUART device closed
2017.01.11 09:59:58 3: Setting myHmUART serial parameters to 115200,8,N,1
2017.01.11 09:59:58 1: /dev/ttyAMA0 reappeared (myHmUART)
Kann mir jemand weiterhelfen woran das liegt?
Die Firmware liess sich ohne Fehlermeldung updaten
Grüsse
Rudi
Zitat von: maseb am 11 Januar 2017, 10:12:45
Hallol,
ich baue mir gerade einen neuen Fhem Server mit Raspberry Pi2 und dem Funkmodul auf.
Im Log kommt aber eine Fehlermeldung und der stat des Funkmoduls steht nur auf opened.
2017.01.11 09:35:01 1: Including fhem.cfg
2017.01.11 09:35:01 3: telnetPort: port 7072 opened
2017.01.11 09:35:02 3: WEB: port 8083 opened
2017.01.11 09:35:02 3: WEBphone: port 8084 opened
2017.01.11 09:35:02 3: WEBtablet: port 8085 opened
2017.01.11 09:35:02 2: eventTypes: loaded 15 events from ./log/eventTypes.txt
2017.01.11 09:35:02 3: Opening myHmUART device /dev/ttyAMA0
2017.01.11 09:35:02 3: Setting myHmUART serial parameters to 115200,8,N,1
2017.01.11 09:35:02 3: myHmUART device opened
2017.01.11 09:35:02 1: Including ./log/fhem.save
2017.01.11 09:35:02 1: usb create starting
2017.01.11 09:35:03 1: usb create end
2017.01.11 09:35:03 2: SecurityCheck: WEB,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.01.11 09:35:03 0: Featurelevel: 5.7
2017.01.11 09:35:03 0: Server started with 11 defined entities (fhem.pl:12966/2017-01-05 perl:5.020002 os:linux user:fhem pid:550)
2017.01.11 09:59:58 1: HMUARTLGW myHmUART unexpected info about Co_CPU_BL received (module crashed?), reopening
2017.01.11 09:59:58 3: myHmUART device closed
2017.01.11 09:59:58 3: Setting myHmUART serial parameters to 115200,8,N,1
2017.01.11 09:59:58 1: /dev/ttyAMA0 reappeared (myHmUART)
Kann mir jemand weiterhelfen woran das liegt?
Die Firmware liess sich ohne Fehlermeldung updaten
Grüsse
Rudi
Ich sehe keine Fehlermeldung!
Und der state open ist genau richtig!
Gruß
Dan
EDIT:
Zitat
2017.01.11 09:59:58 1: HMUARTLGW myHmUART unexpected info about Co_CPU_BL received (module crashed?), reopening
Hab doch Tomaten auf den Augen!
Hmmm....
Fällt mir gerade nix zu ein!
Welche FW ist denn auf dem Modul?
Was liefert ein list myHmUART
Und das ganze dann bitte in code-Tags: '#'...
Gruß, Joachim
Hallo,
ein list myHMUART liefert folgendes
Internals:
AssignedPeerCnt 0
CNT 12
DEF /dev/ttyAMA0
DEVCNT 12
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 11
LastOpen 1484125437.88921
NAME myHmUART
NR 24
PARTIAL
RAWMSG 040202
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 1
msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/1
msgLoadHistoryAbs 1/1/1/1/1/1/1/1/1/1/1/1/0
owner 123456
Helper:
CreditTimer 252
FW 66561
Initialized 1
Ackpending:
LastSendLen:
3
3
Log:
IDs:
Roundtrip:
Delay 0.0032200813293457
Loadlvl:
lastHistory 1484129041.47224
Peers:
Readings:
2017-01-11 10:04:01 D-HMIdAssigned 123456
2017-01-11 10:04:01 D-HMIdOriginal 4F6CA8
2017-01-11 10:04:01 D-firmware 1.4.1
2017-01-11 10:04:01 D-serialNr NEQ1330184
2017-01-11 10:03:57 D-type HM-MOD-UART
2017-01-11 10:04:01 cond ok
2017-01-11 10:09:09 load 1
2017-01-11 10:04:01 loadLvl low
2017-01-11 10:03:57 state opened
Attributes:
hmId 123456
room Funkmodul
Die FW ist die 1.4.1
Die Fehlermeldung im Log
2017.01.11 09:35:03 0: Featurelevel: 5.7
2017.01.11 09:35:03 0: Server started with 11 defined entities (fhem.pl:12966/2017-01-05 perl:5.020002 os:linux user:fhem pid:550)
2017.01.11 09:59:58 1: HMUARTLGW myHmUART unexpected info about Co_CPU_BL received (module crashed?), reopening
2017.01.11 09:59:58 3: myHmUART device closed
Gruss
Rudi
Hallo Rudi,
wie hast Du das Firmware update gemacht? Über FHEM direkt?
Wo hast Du die Datei heruntergeladen? Vielleicht ist bei dem Update doch was schief gegangen? Ich würde das nochmal amchen. Datei nochmal herunterladen.
Gruß Otto
Hallo,
ich habe das update wie in der Wiki beschrieben gemacht. Sowohl über Fhem als auch übers Terminal.
Beide male ohne Fehlermeldung.
Könnte das Problem etwas mit einer falschen Lötstelle zu tun haben.
Ich habe das Modul selbst gelötet und bin mir da unsicher.
Gruss
Rudi
Hallo Rudi,
da muss ich mal in den Plan schauen. Weil eigentlich ... Du kannst flashen, da geht also schonmal die Kommunikation. Und viel mehr ist da nicht.
Es gab mal den Fall, da hatte jemand das Modul verkehrt herum gelötet, da geht aber gar nix.
Du könntest eine Brücke zwischen zwei benachbarten Pins gemacht haben, musst Du nochmal mit der Lupe und viel Licht prüfen. Es gab da noch so ein Reset Pin.
Gruß Otto
ich habe seit gestern ein funkmodul aus dem rt über. sieht aus wie das auf dem HM-MOD-RPI-PCB. frage die sich mir stellt. auf der platine die das funkmodul des HM-MOD-RPI-PCB enthält ist ja nicht wirklich viel drauf? kann man die einzeln bekommen oder einfach nachbauen oder ist da doch mehr drauf als ich denke?
Der HM-MOD-RPI-PCB enthält unter dem Metal-Schirm mehr als die reine Funk-Module, auch wenn sie äusserlich ähnlich aussehen.
Die Adapter-Platine alleine ist trivial.
Hallo zusammen,
ich versuche auch gerade mein Modul ans laufen zu bekommen, bin aber auf ein Problem gestoßen und hoffe ihr könnt mir helfen.
Installiert habe ich es so wie es hier (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_P (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_P)i) beschrieben ist.
Inkl. Update und allem und das hat auch geklappt. Das Modul ist eingebunden und meldet sich mit dem Status "open"
Hier noch das List:
Internals:
AssignedPeerCnt 0
CNT 36
DEF /dev/ttyAMA0
DEVCNT 36
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 4
LastOpen 1484656663.99199
NAME HM.GPIO
NR 53
PARTIAL
RAWMSG 040200
RSSI -44
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 0
msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
owner 123456
Helper:
CreditTimer 20
FW 66561
Initialized 1
Ackpending:
LastSendLen:
3
3
Log:
IDs:
Roundtrip:
Delay 0.00316596031188965
Loadlvl:
lastHistory 1484656667.5354
Peers:
Readings:
2017-01-17 13:37:47 D-HMIdAssigned 123456
2017-01-17 13:37:47 D-HMIdOriginal 4F6E61
2017-01-17 13:37:47 D-firmware 1.4.1
2017-01-17 13:37:47 D-serialNr NEQ1330624
2017-01-17 13:21:03 D-type HM-MOD-UART
2017-01-17 13:37:47 cond ok
2017-01-17 13:37:47 load 0
2017-01-17 13:37:47 loadLvl low
2017-01-17 13:37:43 state opened
Attributes:
group HomeMatic
hmId 123456
room Gateways
In meiner Installation läuft schon schon ein HM-LAN Gateway an einer VCCU und ich hatte eigentlich gedacht ich kann das Modul einfach dazupacken...?!
ich habe die IO-List mit attr VCCU ioList ergänz und beide Gateways werden nun in der VCCU angezeigt. Das LAN Modul mit OK das GPIO-Gateway mit unknown :-(
Kann mir jemand sagen warum und was ich tun muss...?!
Vielen Dank und Gruß
H-Man
Zitatich habe die IO-List mit attr VCCU ioList ergänz
hoffentlich ohne leerzeichen.
ZitatDas LAN Modul mit OK das GPIO-Gateway mit unknown :-(
Kann mir jemand sagen warum und was ich tun muss...?!
zeig doch deine vccu und auch das attr IOList
oder bin ich im Rateforum, ich sag mal "Leerzeichen"
Edit: mist frank war schneller :)
Nein, hier ist natürlich kein Rateforum!
Aber dafür habt ihr beide a) Superchnell und b) auch noch vollkommen richtig geraten!
Es lag natürlich am Leerzeichen! Also gilt mal wieder: Kaum macht man es richtig - funktioniert es!
Vielen Dank für den Hinweis!
Und hier der Vollständigkeit halber noch das List:
Internals:
DEF 123456
HM.GPIO_MSGCNT 11
HM.GPIO_RAWMSG 0500002E438002396B8F1511AB0101C8002B
HM.GPIO_RSSI -46
HM.GPIO_TIME 2017-01-17 14:04:59
IODev LGW01
LASTInputDev LGW01
LGW01_MSGCNT 40
LGW01_RAWMSG 05000027438002396B8F1511AB0101C8002B
LGW01_RSSI -39
LGW01_TIME 2017-01-17 14:04:59
MSGCNT 51
NAME VCCU
NOTIFYDEV global
NR 21
NTFY_ORDER 50-VCCU
STATE LGW01:ok,HM.GPIO:ok,
TYPE CUL_HM
assignedIOs HM.GPIO,LGW01
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
lastMsg No:59 - t:02 s:123456 d:50D1AD 00
protLastRcv 2017-01-17 14:03:06
rssi_at_HM.GPIO min:-46 avg:-40.33 lst:-39 cnt:3 max:-36
rssi_at_LGW01 lst:-38 cnt:1 max:-38 min:-38 avg:-38
Readings:
2017-01-17 14:03:06 CommandAccepted yes
2017-01-17 14:04:26 state LGW01:ok,HM.GPIO:ok,
2017-01-17 14:04:58 unknown_1511AB received
2017-01-12 10:49:32 unknown_221E94 received
2017-01-13 08:41:47 unknown_34181E received
2017-01-17 14:04:59 unknown_396B8F received
2017-01-13 04:14:06 unknown_3C5D60 received
2017-01-17 14:04:58 unknown_3E63AF received
2017-01-12 10:20:10 unknown_417BFC received
2017-01-12 10:04:29 unknown_45CA2F received
2017-01-12 10:03:58 unknown_502BC7 received
2017-01-12 10:02:58 unknown_50D1AD received
2017-01-11 12:51:13 unknown_999999 received
Helper:
HM_CMDNR 89
mId FFF0
rxType 1
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
nextSend 1484658186.79295
prefIO
vccu
ioList:
LGW01
HM.GPIO
Mrssi:
mNo 59
Io:
HM.GPIO -39
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Rssi:
At_hm.gpio:
avg -40.3333333333333
cnt 3
lst -39
max -36
min -46
At_lgw01:
avg -38
cnt 1
lst -38
max -38
min -38
Attributes:
IODev LGW01
IOList LGW01,HM.GPIO
expert 2_raw
group HomeMatic
model CCU-FHEM
room Gateways
subType virtual
webCmd virtual:update
Hallo, kann mir jemand helfen?
Ich bin der Anleitung im Forum gefolgt. Da steht ja das man die Verlinkung kontrollieren soll und evtl. eine Datei ändern was nach Herbst 2016 nicht mehr nötig ist. Ich habe ein Jessie Installation voll upgedated erhalte aber trotzdem
pi@raspberrypi:~ $ ls -l /dev/serial1
lrwxrwxrwx 1 root root 7 Feb 4 20:40 /dev/serial1 -> ttyAMA0
was ja wohl falsch ist. Was muss ich tun um den Link richtig zu stellen?
Zur Info
Internals:
CNT 1
DEF /dev/ttyAMA0
DevState 1
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 5
LastOpen 1486238595.54131
NAME myHmUART
NR 120
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Helper:
Ackpending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 2
time 1486238596.54382
LastSendLen:
3
Log:
IDs:
Readings:
2017-02-04 20:40:35 D-type HM-MOD-UART
2017-02-04 21:03:16 cond init
2017-02-04 20:40:35 loadLvl suspended
2017-02-04 21:03:15 state opened
Noch ein Problem: Beim Versuch des Firmwareupdates bekomme ich:
[//opt/fhem/FHEM/FIRMWARE/coprocessor_update.eq3 is not a valid firmware file! code]
Gibt es noch eine andere Datei?
Hi,
die Anzeige oben ist völlig korrekt. Da muss nichts korrigiert werden.
Aber Dein Modul läuft nicht. Bitte dies befolgen -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
//opt ist eine falsche Pfadangabe
Gruß Otto
Hallo,
das // kam vom falschen einfügen in die Code Marker. Richtig ist:
/opt/fhem/FHEM/FIRMWARE/coprocessor_update.eq3 is not a valid firmware file!
was ist da falsch?
Zitat von: mwiimmer am 04 Februar 2017, 22:28:42
Hallo,
das // kam vom falschen einfügen in die Code Marker. Richtig ist:
/opt/fhem/FHEM/FIRMWARE/coprocessor_update.eq3 is not a valid firmware file!
was ist da falsch?
Ich weiß ja nicht was Du gemacht hast?!? Du postest zwei Probleme die keine sind und fragst was falsch ist.
Der Standard Pfad heißt eigentlich
/opt/fhem/FHEM/firmware/Aber da Dein copy&paste kaputt ist.... ???
Der Pfad spielt überhaupt keine Rolle solange das Modul nicht läuft!
Gruß Otto
OK,
habe die Anleitung noch einmal ganz in Ruhe abgearbeitet und habe dabei einen Schreibfehler bei den Einträgen in in "config.txt" gefunden. Jetzt läuft das Modul und ich konnte die FW updaten. Also Danke für den Stupser nochmal die Anleitung zu befolgen.
Ich fand aber eigentlich dass dashier schon ein Problem ist: ;) ;)
/opt/fhem/FHEM/FIRMWARE/coprocessor_update.eq3 is not a valid firmware file!
Die Meldung führt halt nur in die falsche Richtung wenn das Modul noch nicht läuft.
Hallo zusammen,
hab auch das Funkmodul mit der aktuellen Firmware 1.4.1 am laufen. Daran habe ich drei HM-CC-RT-DN Heizthermostate gepaart.
Empfangen kann ich alles, jedoch kann ich keine Befehle senden.
Mit z.B. set <DEVICE> controlMode manual passiert nichts. Habe auch andere set Befehle ausprobiert.
Hat jemand eine Idee?
Zitat von: darkon am 05 Februar 2017, 20:49:00
Hallo zusammen,
hab auch das Funkmodul mit der aktuellen Firmware 1.4.1 am laufen. Daran habe ich drei HM-CC-RT-DN Heizthermostate gepaart.
Empfangen kann ich alles, jedoch kann ich keine Befehle senden.
Mit z.B. set <DEVICE> controlMode manual passiert nichts. Habe auch andere set Befehle ausprobiert.
Hat jemand eine Idee?
Nicht am Device sondern beim richtigen Kanal...
...Clima oder Climate...
Grad nur mobil daher kurz...
...immer vorausgesetzt es ist tatsächlich korrekt gepaired...
PairedTo bzw. R-PairCentral dort muss die HMID stehen ohne _set...
Gruß, Joachim
Danke schonmal,
die CUL_HM hat diese Option ja nur in der Clima. Also versuche es auch mit dem Device Clima.
Jedoch finde ich kein PairedTo oder ähnliches. Müsste das in den Internals, Readings oder Log zu finden sein?
Mach doch mal ein list vom Gerät:
list DeviceName
in dem WebCmd-Fenster...
Und dann dort suchen...
...oder hier posten...
#-Tags verwenden...
Kannst aber auch einfach den set absetzen, wenn's klappt dann ist wohl gepaired...
Gruß, Joachim
Das pairing wurde anscheinend nicht richtig durchgeführt.
Kann ich das nachträglich noch machen oder muss ich alle devices löschen und mit autocreate neu paaren?
Normalerweise einfach neu pairen...
Löschen eigentl. gar nicht.
Max. das Gerät zurücksetzen aber nur, wenn es bereits mal mit einer anderen HMID gepaired war...
Poste doch mal ein list...
Gruß, Joachim
So... habe jetzt das Thermostat auf Werkseinstellungen zurückgesetzt und neu gepaired.
Jetzt kann ich das Thermostat steuern, jedoch mit einem delay von ca. 20-30 Sekunden. Ist das Normal?
Auch R_pairCentral oder R-PairedTo existiert bei mir nicht.
Hier mein List:
Internals:
CFGFN
DEF 4F163F04
NAME WZ_Heizung_Clima
NOTIFYDEV global
NR 3954
STATE T: 23.6 desired: 20.0 valve: 0
TYPE CUL_HM
chanNo 04
device WZ_Heizung
Readings:
2017-02-05 21:48:55 CommandAccepted yes
2017-02-05 21:46:12 R-boostPos 80 %
2017-02-05 21:46:12 R-btnNoBckLight off
2017-02-05 21:46:12 R-dayTemp 21 C
2017-02-05 21:46:12 R-daylightSaveTime on
2017-02-05 21:46:12 R-modePrioManu all
2017-02-05 21:46:12 R-modePrioParty all
2017-02-05 21:46:12 R-nightTemp 17 C
2017-02-05 21:46:12 R-noMinMax4Manu off
2017-02-05 21:46:12 R-regAdaptive on
2017-02-05 21:46:12 R-showInfo time
2017-02-05 21:46:08 R-sign off
2017-02-05 21:46:12 R-tempOffset 0.0K
2017-02-05 21:46:12 R-valveOffsetRt 0 %
2017-02-05 21:46:12 R-winOpnBoost off
2017-02-05 21:46:18 R_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-02-05 21:46:18 R_tempList_State verified
2017-02-05 21:46:14 RegL_01. 08:00 00:00
2017-02-05 21:46:18 RegL_07. 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:8E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0F CB:1E CC:1E CD:0F CE:1E CF:1E 00:00
2017-02-05 21:48:54 ValvePosition 0
2017-02-05 21:48:55 boostTime -
2017-02-05 21:48:55 controlMode auto
2017-02-05 21:48:55 desired-temp 20.0
2017-02-05 21:48:54 measured-temp 23.6
2017-02-05 21:48:55 partyEnd -
2017-02-05 21:48:55 partyStart -
2017-02-05 21:48:55 partyTemp -
2017-02-05 21:48:55 recentStateType ack
2017-02-05 21:48:55 state T: 23.6 desired: 20.0 valve: 0
Helper:
peerIDsRaw ,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shregr:
07 00
Shadowreg:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,
Nachtrag: Der Delay beträgt teilweise sogar 2-3 Minuten. :-\
Es ist ein batteriebetriebenes Gerät welches normalerweise ohne burst (sofort auf Nachrichten reagieren) arbeitet um Batterien zu sparen...
Wenn du sofort eine Reaktion willst musst du burst aktivieren...
Mal Modellname und fhem in google eingeben und dann im Wiki nach burst suchen...
Gruß, Joachim
P.S.: wäre aber wahrsch. ohne zurücksetzen auch gegangen. Evtl. sogar mit erneutem getConfig...
Zitat von: darkon am 05 Februar 2017, 21:52:57
Auch R_pairCentral oder R-PairedTo existiert bei mir nicht.
Diese existieren hoffentlich bei dem Haupgerät WZ_Heizung nicht bei den Channels.
Gruß Otto
ZitatHallo, ich versuche mich auch gerade an dem Funkmodul und habe dazu extra ein Testsystem aufgesetzt. Ich versuche das ganze auf einem Banana PI mit Jessie. Ich konnte das Modul in FHEM auch anlegen und dort auch die FW aktualisieren, jedoch bekommen ich keine Geräte zu sehen nur "Unknown code".
Hey wie hast du das auf dem BananaPi zum Laufen gebracht?
Ich wollte hier auch nach dem Wiki vorgehen, aber bei mir existieren schon mal die folgenden Dateien gar nicht:
/boot/config.txt
/boot/cmdline.txtIch habe diese dann mal angelegt, komme aber dennoch nicht weiter.
Wenn ich folgendes ausführe:
ls -l /dev/ttyAMA0bekomme ich diese Meldung:
ls: cannot access /dev/ttyAMA0: No such file or directory
Viele Grüße, Thomas
Hallo,
bin Anfänger und möchte über HM-MOD-RPI-PCB Mein Funkmodul für Rollosteuerung ansprechen.
Habe mich an dem WIKI gehalten https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
aber leider gibt es beim flashen Probleme, aber nicht das er die firmware nicht nimmt, sondern er kann das Modul nicht initialisieren.
~/hmcfgusb# ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
HM-MOD-UART flasher version 0.103-git
Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.
Initializing HM-MOD-UART...
Communication with the module timed out, is the serial port configured correctly?
Kann mir wer helfen?
Gruß,
Jörg
Zwischenruf: Die Schnittstelle "ttyAMA0" (also die interne serielle) ist richtig freigemacht?
Welcher Pi (2 oder 3)? Welches System?
Und ist das Modul richtig zusammengelötet? Die Anleitung ist nicht 100% narrensicher, wir hatten das hier (https://forum.fhem.de/index.php/topic,41203.msg535923/topicseen.html#msg535923) tatsächlich schon einmal ...
Oder ist FHEM schon aktiv auf der Schnittstelle und es wird (warum auch immer) nicht über FHEM geflasht sondern auf Systemebene.
Gruß Otto
Ich habe gestern einen RPi 2 frisch mit aktuellem Raspbian Jessie light aufgesetzt (inkl. apt-get update|upgrade). Danach habe ich mich an die Wikianleitung gehalten und es hat problemlos funktioniert. Die aktuelle FW habe ich über FHEM auf dem Modul installiert. Alles in allem funktioniert die Beschreibung im Wiki so wie sie ist.
Was man meines Erachtens evtl. für nicht ganz so Linux affine Menschen verbessern könnte, wäre die RPi (RPi 2/3) spezifischen Konfigurationsschritte klarer herauszuarbeiten. Auch sind (zumindest aktuell) die beiden Links auf die Modul FW verwirrend (welche soll ich jetzt nehmen?!), da beide auf die selbe FW Version zeigen.
Zitat von: Jorge3711 am 11 Mai 2017, 09:23:06
Was man meines Erachtens evtl. für nicht ganz so Linux affine Menschen verbessern könnte, wäre die RPi (RPi 2/3) spezifischen Konfigurationsschritte klarer herauszuarbeiten. Auch sind (zumindest aktuell) die beiden Links auf die Modul FW verwirrend (welche soll ich jetzt nehmen?!), da beide auf die selbe FW Version zeigen.
Hi,
danke für Dein Feedback! Ich schaue mir das an und überarbeite das mal mit diesen Hinweisen. Ich melde mich zurück.
Gruß Otto
Zitat von: Pfriemler am 10 Mai 2017, 22:26:05
Zwischenruf: Die Schnittstelle "ttyAMA0" (also die interne serielle) ist richtig freigemacht?
Welcher Pi (2 oder 3)? Welches System?
Und ist das Modul richtig zusammengelötet? Die Anleitung ist nicht 100% narrensicher, wir hatten das hier (https://forum.fhem.de/index.php/topic,41203.msg535923/topicseen.html#msg535923) tatsächlich schon einmal ...
Hallo, es ist ein Pi 3 mit Jessie Lite. Die Lötstellen habe ich mir nochmal angesehen, ist alles ok.
Wie mache ich die Schnittstelle richtig frei?
In der Anleitung steht ich soll sie überprüfen:
root@mainrasp:~/hmcfgusb# ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Mai 12 17:59 /dev/ttyAMA0
Bei FHEM in der fehm.cgf habe ich am Ende folgendes eingefügt:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId 6958ffIn der Anleitung steht ich kann die Firmware auch über FHEM aktualisieren, habe folgendes eingegeben:
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3
Die Seite wird nur kurz neu geladen, aber ich bekomme keine Rückmeldung von FHEM.
Würde mich auf Hilfe freuen.
Gruß,
Jörg
ZitatWie mache ich die Schnittstelle richtig frei?
steht im wiki https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Vorbereitung_serielle_Schnittstelle_unter_Jessie
ZitatBei FHEM in der fehm.cgf habe ich am Ende folgendes eingefügt:
bitte nicht die fhem cfg editieren sonder dafür das eingabefenster in fhemweb nutzen!!!!!!!
im wiki steht auch wie man es ohne fhem flashed (was für mich bisher am besten funktioniert hat)
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Alternative_Methode_zum_Firmware_Update_ohne_FHEM
Zitat von: Pfriemler am 10 Mai 2017, 22:26:05
Die Anleitung ist nicht 100% narrensicher
naja, bilder deuten ist halt nicht jedermanns sache (und das farb-pdf der anleitung deutlich besser). eigentlich nicht vorstellbar das man da was falsch macht (außer man hat seine brille nicht auf und schaut die bilder nur flüchtig an)
Ich habe die fhem.cfg über die Weboberfläche bearbeitet, nicht direkt über den nano oder so.
Ich habe mich genau an die Anleitung gehalten, die Vorbereitung der Schnittstelle unter Jessie:
Einziger Unterschied, ich habe den Befehl: systemctl disable serial-getty@ttyAMA0.service
mit sudo ausführen müssen, da sonst eine Fehlermeldung kam:
sudo systemctl disable serial-getty@ttyAMA0.service
Auch das flashen ohne fhem.
Ging aber nicht, gleiche Fehlermeldung:
Communication with the module timed out, is the serial port configured correctly?
An was kann es noch liegen?
Oder soll ich eine andere SD mit jessie neu aufsetzen und nochmal probieren?
Danke schon mal.
Hi,
auch das geprüft?ls -l /dev/serial1
Mit welchem Editor die config Dateien bearbeitet? (Stichwort lf am Zeilenende)
Den grünen Kasten im Wiki beachtet?
Sorry aber die Linux Basics (z.B. Verwendung sudo) schreibt keiner in jeden Artikel. Das würde das ganz immer zu sehr aufblähen
Vielleicht sollte man dazu auch mal einen Artikel finden/schreiben den man per default verlinkt.
Es ging im Hinweis von Pfriemler nicht um die Qualität der Lötstellen, sondern darum das beide Leiterplatten verkehrt zusammen gelötet wurden.
Gruß Otto
Hallo,
das sudo nicht in jeden Artikel erwähnt wird finde ich auch nicht schlimm, wollte es nur zusätzlich als Hinweis schreiben.
serial1 ist nicht auf ttyS0 verlinkt. Aber in der Datei /lib/systemd/system/hciuart.service gibt es auch kein ttyAMA0. Die sieht wie folgt aus:
[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-serial1.device
[Service]
Type=forking
ExecStart=/usr/bin/btuart
[Install]
WantedBy=multi-user.target
Kann es daran liegen? Was für ein Eintrag fehlt hier?
Zusammengebaut sind die Leiterplatten ganz sicher richtig...
Danke
Gruß Jörg
Hallo Jörg,
ich glaube so kommen wir nicht weiter. Meine /lib/systemd/system/hciuart.service sieht anders aus. Aber wir suchen ja kein Problem bei BT. Beschreibe doch bitte genau die Schritte die Du gemacht hast.
Poste vielleicht auch die Ausgabe von ls -l /dev/ser*
Edit: Mir fällt noch ein: Da gab es auch eine Beobachtung, dass der initialUsbCheck die ttyAMA0 irgendwie "stört" kannst Du bitte attr initialUsbCheck disable 1
setzen und komplett neu starten?
Gruß Otto
Hallo,
ich habe FHEM installiert. Danach habe ich die Anleitung befolgt:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
in /boot/config.txt folgende Zeilen ergänzt (Habe einen PI3):
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
Aus /boot/cmdline.txt console=serial0,115200 entfernt.
Danach:
sudo systemctl disable serial-getty@ttyAMA0.service
groups fhem
Ausgabe: fhem : dialout tty
Schnittstelle kontrolliert: ls -l /dev/ttyAMA0
Ausgabe crw-rw---- 1 root dialout 204, 64 Mai 16 20:01 /dev/ttyAMA0
ls -l /dev/serial1 Ausgabe: ls: Zugriff auf /dev/serial1 nicht möglich: Datei oder Verzeichnis nicht gefunden
Dann von der Seite das hier getan: Fehlermeldung:Initializing HM-MOD-UART...
Communication with the module timed out, is the serial port configured correctly?
Anscheinend ist ttyAMA0 auf /dev/serial0 verlinkt:
ls -l /dev/ser* Ausgabe: lrwxrwxrwx 1 root root 7 Mai 12 21:51 /dev/serial0 -> ttyAMA0
Bei Eingabe von attr initialUsbCheck disable 1 kommt folgendes: bash: attr: Kommando nicht gefunden.
in der fhem.cfg habe ich folgendes hinzugefügt:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId 6958ff
Allerdings erschließt sich mir nicht warum ich hier als id eine willkürliche hex-Adresse angeben soll... aber so weit bin ich ja noch nicht :)
Würde mich weiter auf Hilfe freuen...
Gruß und Danke,
Jörg
Zitatlrwxrwxrwx 1 root root 7 Mai 12 21:51 /dev/serial0 -> ttyAMA0
da müsste
Zitatlrwxrwxrwx 1 root root 5 Jan 11 20:00 /dev/serial1 -> ttyS0
bei rauskommen.
das problem hatte ich gestern auch. erst nach mehrmaligem durchspielen /kontrollierne der änderungen und wirklich einmal den pi stromlos machen haben sie gegriffen
etwas offtopic: hier ist das schöner /umfangreicher mit mehr hintergrundinfos beschrieben http://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/
Hallo Jörg,
bei mir sind die seriellen Schnittstellen so, allerdings ist die Installation jetzt schon ein paar Tage her und nicht mit der letzten Jessie Version. Ich kann nicht ausschließen, dass sich da etwas geändert hat. War in der Vergangenheit leider so, von Version zu Versionlrwxrwxrwx 1 root root 7 May 13 18:13 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 May 13 18:13 /dev/serial1 -> ttyS0
Es ist also etwas mit BT anders?! Das sollte aber eigentlich nicht stören.
Bitte gib den Befehl attr initialUsbCheck disable 1nicht in der Linux Shell ein, sondern dies ist das Setzen eines Attributes in FHEM. Dieser Befehl gehört in die FHEM Kommandzeile (Browser) danach musst Du save machen (FHEM Kommando) bevor du alles neu startest.
Ich kann später noch weitere Dinge an einem anderen System testen.
Gruß Otto
Hallo Jörg,
ich behaupte mal Deine /boot/config.txt hat nicht den notwendigen Inhalt. Auf einem Testsystem ergibt sich folgendes:
Ohne Modifikation der /boot/config.txt ls -l /dev/ser*
lrwxrwxrwx 1 root root 7 Mai 4 19:35 /dev/serial1 -> ttyAMA0
Mit Modifikation der /boot/config.txtenable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
ls -l /dev/ser*
lrwxrwxrwx 1 root root 7 Mai 17 12:35 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Mai 17 12:35 /dev/serial1 -> ttyS0
Der Inhalt der /lib/systemd/system/hciuart.service hat sich tatsächlich in der aktuellen Situation wieder geändert. Ich denke aber, der ist seit langem nicht mehr relevant. Da muss man nichts mehr ändern.
Mit welchem Editor hast du die /boot/config.txt bearbeitet?
Gruß Otto
Hallo danke für eure Bemühungen, aber leider funktioniert es noch nicht.
Nach Eingabe von attr initialUsbCheck disable 1 und save bei FHEM habe ich den PI3 neu gestartet. Hatte ihn auch vom Stromnetz getrennt.
Leider kein Erfolg.
Die /boot/config.txt schaut im Moment so aus:
# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
start_x=0
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
Editiert habe ich ihn mit dem nano Editor... echt schade..
schalte auch mal testweise bt ab
Zitat# Enable uart
enable_uart=1
# disable pi3 onboard bt
dtoverlay=pi3-disable-bt
Hi Jörg,
bist Du bitte so nett und postest ein Bild von Deinem Modul? Gerne auch wie es auf dem Pi steckt.
Gruß Otto
Hier ein Foto
Sorry, aber ich habe es geahnt! Verkehrt gelötet! Der Stecker ist auf der verkehrten Seite! Schau hier -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Gruß Otto
Ach du meine Güte, Asche über mein Haupt. Schon sehr peinlich... da geb ich dir ein Eis aus. Danke.
Zitat von: Otto123 am 18 Mai 2017, 22:02:18
Sorry, aber ich habe es geahnt! Verkehrt gelötet! Der Stecker ist auf der verkehrten Seite! Schau hier -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Gruß Otto
Nicht nur die Buchsenleiste ist auf der falschen Seite! Auch das Funkmodul! 8)
Auf der anderen Platinenseite sollte auch eine rechteckige Markierung sein in die das Funkmodul hinein gehört. 8) 8) 8)
Gruß
Dan
Moin,
da hat Dan natürlich Recht, das habe ich gestern Abend auf die Schnelle nicht gecheckt. "Konsequent" alles gedreht.
Wobei man das Funkmodul auch auf die Seite löten kann, aber eben anders herum. Dann baut das Modul nicht so hoch und die normalen Gehäuse passen.
Gruß Otto
Ja, weil eben alles gedreht war ist es mir nicht aufgefallen. :)
Bei
ls -l /dev/ser* kommt noch immer das gleiche:
Zitatlrwxrwxrwx 1 root root 7 Mai 19 19:33 /dev/serial0 -> ttyAMA0
Also kein serial1 sondern serial0.
Aber Update funktioniert.
Jetzt muss ich das Teil "nur" noch ansprechen damit ich meine Jalousie hoch und runter fahren lassen kann.
Danke euch.
EDIT: Wenn ich nun den Aktor über FHEM ansprechen möchte muss ich den doch erst mal bekannt machen.
Ich habe folgendes in die fhem.cfg am schluss eingegeben:
define JalousieWohnzimmer CUL_HM 17E43C
attr JalousieWohnzimmer devInfo 010100
attr JalousieWohnzimmer firmware 1.5
attr JalousieWohnzimmer hmClass receiver
attr JalousieWohnzimmer model HM-LC-BL1-FM
attr JalousieWohnzimmer room Wohnzimmer
attr JalousieWohnzimmer serialNr OEQ0048811
attr JalousieWohnzimmer subType blindActuatorBeim Speichern kommt:
ERROR:
JalousieWohnzimmer: unknown attribute devInfo. Type 'attr JalousieWohnzimmer ?' for a detailed list. JalousieWohnzimmer: unknown attribute hmClass. Type 'attr JalousieWohnzimmer ?' for a detailed list.
Muss ich die attribute erst definieren? Fehlt ein Modul bei fhem?
Gruß, Jörg
Zitat von: PerlJoe am 19 Mai 2017, 20:06:40
EDIT: Wenn ich nun den Aktor über FHEM ansprechen möchte muss ich den doch erst mal bekannt machen.
Ich habe folgendes in die fhem.cfg am schluss eingegeben:
Hallo Jörg,
eingeben musst du gar nichts und schon gar nicht direkt in die cfg!!
Eigentlich "nur" den definierten HMUART oder falls vorhanden die vccu (empfehlenswert) in den Anlernmodus versetzen:
set HMUART hmPairForSec 60
(oder wie immer dein HMUART heißt)
und dann den Aktor laut Bedienungsanleitung (Anlernen an Zentrale) in den Anlernmodus bringen.
Autocreate sollte nat. aktiv sein (Standard) und dann legt fhem das Gerät automatisch und richtig ohne Fehler an...
Danach save config und gut...
Gruß, Joachim
Hallo Joachim,
ok, dann gebe ich set myHmUART hmPairForSec 60 bei der FHEM Weboberfläche ein und drücke enter.
Danach ist die seite weiß und bleibt auch so...
Auch wenn ich update schreibe und abschicke wird die Seite weiß und es rührt sich nichts.
Du kannst auch auf die Detailseite des HMUART gehen und dort per Klick und Klack auf hmPairForSec stellen...
Bzw. hast du nach der Eingabe (sollte das gleiche sein) den Aktor in den Anlernmodus laut Bedienungsanleitung versetzt!?
Kam dann ein rotes Fragezeichen bei save config!?
Autocreate ist aktiv!?
EDIT: evtl. mal in einem 2ten Tab den Eventmonitor öffnen, da sollte dann was kommen...
Gruß, Joachim
Autocreate ist in der FHEM.cfg aktiv.
Sorry, bin hier noch Anfänger und habe keine Ahnung von dem was du da schreibst.
Auf die Detailseite des HMUART gehen? Wo ist die denn?
Muss ich da auf Unsorted und dann auf myHmUART - opened gehen?
Da gibt es einen "set" Button. hier habe ich hmPairForSec ausgewählt, in das Textfeld 60 eingegeben und auf den set-Button geklickt.
Dann hat er die Seite refresht und das wars...
Achso, dann wartet er 60 Sekunden und "hört" auf ein Anlernsignal? Dann muss ich bei dem Aktor noch einen Taster hinbauen...
Habe ich mir das so richtig zusammengereimt? :)
Gruß und Danke, Jörg
Ja so in etwa...
Eigentlich laut Bedienungsanleitung des Aktors: Anlernen an Zentrale (wie bereits geschrieben) und dann halt alles was für die Zentrale beschrieben ist in fhem durchführen:
set HMUART hmPairForSec 60
Du kannst auch eine andere Zahl nehmen, wenn du schneller bist weniger als 60sec und wenn du langsamer bist auch mehr ;)
Aber immer nur ein Gerät pro setzen auf hmPairForSec!
Also NICHT set HMUART hmPairForSec 210000 und dann einfach ein Gerät nach dem anderen anlernen...
EDIT: Und dann nicht vergessen save config zu drücken, sonst sind die angelernten Geräte nach einem Neustart wieder weg...
Gruß, Joachim
Dankeschön, hat geklappt.
Außer das ich jetzt nur den Schalter 1 per FHEM bedienen kann. Muss ich den 2. extra anlernen?
Was meinst du mit Schalter?
Auf/Ab!?
Sollten eigentlich/vermutlich 2 Kanäle angelegt worden sein...
Wobei wenn ich im Wiki schaue sieht das anders aus...
...aber wie gesagt ich habe diesen Aktor nicht...
https://wiki.fhem.de/wiki/HM-LC-BL1-FM_Funk-Jalousieaktor
Aber dazu vielleicht diesen Thread verlassen und einen neuen aufmachen bzw. einen bereits passenden (so vorhanden) nutzen...
Gruß, Joachim
Hm mein HMLANGW verliert immer die Verbindung im Log:
2017.06.05 10:29:07 3: Opening hmlan1:keepAlive device 192.168.2.41:2001
2017.06.05 10:29:07 1: 192.168.2.41:2000 reappeared (hmlan1)
2017.06.05 10:29:07 3: hmlan1:keepAlive device opened
2017.06.05 10:29:07 3: HMUARTLGW hmlan1 BidCoS-port opened
2017.06.05 10:29:07 3: HMUARTLGW hmlan1:keepAlive KeepAlive-port opened
2017.06.05 10:29:11 1: HMUARTLGW hmlan1 did not respond for the 1. time, resending
2017.06.05 10:29:14 1: HMUARTLGW hmlan1 did not respond for the 2. time, resending
2017.06.05 10:29:17 1: HMUARTLGW hmlan1 did not respond for the 3. time, resending
2017.06.05 10:29:20 1: HMUARTLGW hmlan1 did not respond after all, reopening
2017.06.05 10:29:20 3: hmlan1 device closed
2017.06.05 10:29:21 3: Opening hmlan1:keepAlive device 192.168.2.41:2001
2017.06.05 10:29:21 1: 192.168.2.41:2000 reappeared (hmlan1)
2017.06.05 10:29:21 3: HMUARTLGW hmlan1 BidCoS-port opened
2017.06.05 10:29:21 3: hmlan1:keepAlive device opened
2017.06.05 10:29:21 3: HMUARTLGW hmlan1:keepAlive KeepAlive-port opened
2017.06.05 10:29:25 1: HMUARTLGW hmlan1 did not respond for the 1. time, resending
2017.06.05 10:29:28 1: HMUARTLGW hmlan1 did not respond for the 2. time, resending
also ich habe nun alles gemacht was im Wiki steht aber mein HM-LGW-O-TW-W-EU bekommt nicht COND: ok .. immer Init und es startet neu im LOG:
2017.06.05 20:48:25 3: Opening hmlan1:keepAlive device 192.168.2.66:2001
2017.06.05 20:48:25 1: 192.168.2.66:2000 reappeared (hmlan1)
2017.06.05 20:48:26 3: HMUARTLGW hmlan1 BidCoS-port opened
2017.06.05 20:48:26 3: hmlan1:keepAlive device opened
2017.06.05 20:48:26 3: HMUARTLGW hmlan1:keepAlive KeepAlive-port opened
2017.06.05 20:48:30 1: HMUARTLGW hmlan1 did not respond for the 1. time, resending
2017.06.05 20:48:33 1: HMUARTLGW hmlan1 did not respond for the 2. time, resending
2017.06.05 20:48:36 1: HMUARTLGW hmlan1 did not respond for the 3. time, resending
2017.06.05 20:48:39 1: HMUARTLGW hmlan1 did not respond after all, reopening
2017.06.05 20:48:39 3: hmlan1 device closed
2017.06.05 20:48:40 3: Opening hmlan1:keepAlive device 192.168.2.66:2001
2017.06.05 20:48:40 1: 192.168.2.66:2000 reappeared (hmlan1)
2017.06.05 20:48:40 3: hmlan1:keepAlive device opened
2017.06.05 20:48:40 3: HMUARTLGW hmlan1 BidCoS-port opened
2017.06.05 20:48:40 3: HMUARTLGW hmlan1:keepAlive KeepAlive-port opened
2017.06.05 20:48:44 1: HMUARTLGW hmlan1 did not respond for the 1. time, resending
2017.06.05 20:48:47 1: HMUARTLGW hmlan1 did not respond for the 2. time, resending
Feste IP .. Verschlüsselung aus alles schon versucht. Vielleicht ist das Gerät kaputt??
Hi Chris,
richtig zusammengebaut?!
Hatten wir auch schon (einige Male)...
Poste doch mal ein Bild...
...oder zwei...
Gruß, Joachim
naja hab es gebraucht gekauft.... Gerät aufmachen und Bilder Posten?
Du hast keinen basierend auf dem Modul: HM-MOD-RPI-PCB!?
Hast einen "echten" HMLAN?
Gruß, Joachim
Hinten steht drauf:
HM-LGW-O-TW-W-EU Funk Lan Gateway
Poste doch mal ein list von dem Gerät.
Und bitte: code-Tags verwenden ('#' im Menü)...
Nach welchem Wiki?
Welche FW hat das Gerät?
Gruß, Joachim
CNT 110
DEF 192.168.2.66
DEVCNT 108
DevState 1
DevType LGW
DeviceName 192.168.2.66:2000
FD 4
LastOpen 1496729885.26645
NAME hmlan1
NR 21
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Helper:
Ackpending:
110:
cmd 00
dst 0
frame FD0003006E007C06
time 1496729886.27105
LastSendLen:
3
Log:
IDs:
Readings:
2017-06-06 08:18:05 D-LANfirmware 1.1.5
2017-06-06 08:18:05 D-serialNr MEQ0460719
2017-06-06 08:18:05 D-type eQ3-HM-LGW
2017-06-06 08:18:06 cond init
2017-06-05 20:44:29 loadLvl suspended
2017-06-06 08:18:05 state opened
Keepalive:
CNT 109
DEVCNT 108
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.2.66:2001
FD 10
LastOpen 1496729885.28532
NAME hmlan1:keepAlive
NR 3061
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1496729896.31759
Log:
Resolve 1
IDs:
Readings:
2017-06-06 08:18:05 state opened
Lgwhash:
Attributes:
hmId 001111
lgwPw Fb*****Ee4
Da er ja alle Daten ausgelesen hat kann er ja auch etwas erreichen.
Hallo,
Zitat von: ChrisW am 06 Juni 2017, 08:19:02
frame FD0003006E007C06
Das ist der erste Frame, den Fhem an das Koprozessormodul schickt (Betriebsmodusabfrage) und darauf antwortet es nicht.
Zitat
Readings:
2017-06-06 08:18:05 D-LANfirmware 1.1.5
2017-06-06 08:18:05 D-serialNr MEQ0460719
2017-06-06 08:18:05 D-type eQ3-HM-LGW
Diese Daten kommen vom LAN-Prozessor und nicht vom Rf-Koprozessor.
Zitat
Da er ja alle Daten ausgelesen hat kann er ja auch etwas erreichen.
Ja, den LAN-Prozessor. Anscheinend antwortet aber das Rf-Koprozessormodul überhaupt nicht. Es gab da wohl bei den ersten Baureihen des LGW ein Problem, bei dem relativ viele Gateways mit so einem Fehler gestorben sind (soweit ich das mit den Einträgen im Homematic-Forum korrelieren kann).
Sieht also leider nach einem (bekannten) HW-Problem aus -> Anfrage an ELV wegen Umtausch.
EDIT: Ein Link zum anderen Forum: https://homematic-forum.de/forum/viewtopic.php?f=26&t=28669&p=256644#p256644
Viele Grüße
Michael
Danke für die Info mal sehen ob ich es bei ELV getauscht bekomme ..
ich habe zwei HMUART Sticks im Einsatz die sehr zufriedenstellend laufen, nur eine Fernbedienung HM-RC-4-3 macht Zicken. Bei Tastendruck krieg ich das im LOG:
2017.06.07 07:55:11 0: HMUARTLGW hmUSB1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
2017.06.07 07:55:11 0: HMUARTLGW hmUSB1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
2017.06.07 07:55:11 0: HMUARTLGW hmUSB1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
Eine VCCU habe ich zugewiesen, die Meldungen kommen trotzdem.
Die log-Meldungen würden mich nicht so stören, aber leider kommt auch kein Ack von einem virtuellen HM device an (bei der Fernbedienung praktisch damits nicht rot leuchtet).
Habe dann testweise einen CUL als bevorzugtes IODev eingetragen, mit dem funktioniert alles reibungslos.
Hat jemand eine Idee?
ELV tauscht es nicht aus weil ich keine Rechnung habe .. Kann man da was erkennen wenn ich es öffne ?
Hallo,
Zitat von: Wetterhexe am 07 Juni 2017, 08:40:35
2017.06.07 07:55:11 0: HMUARTLGW hmUSB1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
Benutze ein virtuelles Gerät der VCCU und keinen eigenständigen virtuellen Aktor mit eigener hmId.
Zitat von: ChrisW am 07 Juni 2017, 16:50:11
ELV tauscht es nicht aus weil ich keine Rechnung habe .. Kann man da was erkennen wenn ich es öffne ?
Ich würde mal den Vorbesitzer nach der Rechnung fragen.
Hatte noch kein defektes GW in der Hand, deswegen weiss ich nicht, ob man da irgendwas erkennt.
Viele Grüße
Michael
Zitat von: mgernoth am 08 Juni 2017, 10:45:19
Benutze ein virtuelles Gerät der VCCU und keinen eigenständigen virtuellen Aktor mit eigener hmId.
Danke, du bist mein Held! ;)
Hatte die Meldung wohl falsch interpretiert ... funktioniert wunderbar
Zitat von: mgernoth am 08 Juni 2017, 10:45:19
Benutze ein virtuelles Gerät der VCCU und keinen eigenständigen virtuellen Aktor mit eigener hmId.
Hat das einen tieferen Grund?
Ich habe nämlich aus den Zeiten ohne vCCU noch einige virtuelle Geräte, die ich ohne Not nur ungern umstellen möchte.
Hallo,
ich habe folgendes Problem:
Habe den HM-MOD-RPI-PCB nach der Wiki eingerichtet und habe bei diesem Punkt ein Problem.
Kontrolle:
ls -l /dev/serial1
bekomme ich folgende Ausgabe:
ls: Zugriff auf /dev/serial1 nicht möglich: Datei oder Verzeichnis nicht gefunden
Das hat zur Folge das ich die Verlinkung nicht Prüfen kann.
Anscheinend fehlt bei mir die Datei!
Ich verwende als Linux das "Wheezy"
Kann mir jemand helfen hier weiter zu kommen?
Edit:
Habe mir inzwischen selbst helfen können.
Wer noch einen RPI2 mit "Wheezy" verwendet, hier gibt es das anscheinend nicht (noch nicht, erst im "Jessie" ab Mitte 2016).
Habe einfach weiter gemacht und das Gerät in Fhem angelegt.
Läuft!
Danke
Guten Morgen namor,
ich habe einen Hinweis im Wiki ergänzt.
Gruß Otto
Gibt's noch was zu beachten, wenn man das ganze auch Debian Stretch aufsetzt (RasPi 3)?
Gruß
Volker
Moin Volker,
was erwartest Du für eine Antwort? Ja oder Nein?
Es läuft unter Stretch. Aber klar gibt es das Übliche zu beachten, steht eigentlich alles im Wiki (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi).
Gruß Otto
Hallo Otto,
vielleicht war ich da ein bisschen plump 8)
von Wheezy auf Jessie gab es ja schon einige Änderungen (wie in der Wiki nachzulesen ist)
Von Stretch steht da aber nix, und ich da hat sich wohl auch einiges getan, was man allgemein so liest. Deswegen interessiere ich mich dafür, ob Probleme zu erwarten sind durch Änderungen in der Konfiguration. Möchte gerne aus Performance-Gründen von Raspi2 Jessie auf Raspi3 Stretch wechseln und von CUL auf HM-MOD-RPI-PCB. Eine WLan-Anbindung brauche ich nicht (Kabel), aber BT schon wegen Presence-Erkennung.
Wäre halt bescheiden, wenn ich nach dem Umstieg in 3 Baustellen auf Fehlersuche gehen muss (Änderung Hardware, Änderung System, Änderung HM-Anbindung)
Gruß
Volker
Hallo Volker,
also ich meine ich habe mir das diesbezüglich alles angesehen und bezüglich des Moduls gibt es keine Änderungen zwischen den letzten Versionen von Jessie und Stretch.
Da Du die Hardware komplett wechseln willst ist es doch ziemlich easy:
Du installierst auf dem neuen alles neu und schaust ob alles richtig geht.
Wenn Du damit zufrieden bist, machst Du ein backup von FHEM und auf dem neuen ein Restore von FHEM.
Hast Du schon eine VCCU? Die macht den Umstieg von CUL auf den anderen IO einfacher.
Gruß Otto
Hallo zusammen,
Ich habe seit ein paar Wochen einen RPi-3 mit Z-Wave USB Stick am laufen. Wollte nun in die wunderbare Homematic Welt eintauchen und den RPi um diese Funktion erweitern. Dazu habe ich mir ein entsprechendes HM-MOD-RPI-PCB besorgt, zusammengelötet, FW geflasht und als HMUARTLGW device in FHEM angelegt.
Ich frage mich jetzt,
1) was der Unterschied zwischen dieser Methode und dem Vorgehen in der Anleitung von ELV ist, bei dem ich noch die OCCU SW von EQ-3 installieren müsste um eine vollwertige CCU2 zu bekommen.
2) Macht das Sinn?
3) Auf dem gleichen RPi?
4) oder reicht das HMUARTLGW device völlig?
5) Oder ist hier eine VCCU eine gute Idee?
6) Und was wäre der Unterschied zu der ELV OCCU2 Vorgehensweise?
Bin ein echter Neueinsteiger für Homematic und daher auf euer Know How angewiesen. Mein Verständnis ist es auch, dass dieses Modul sowohl Homematic als auch Homematic IP Geräte steuern kann. Ein CUL Stick ala Busware jedoch nur Homematic Geräte.
Gruß,
Mochel
Hi Mochel,
1. Das eine ist FHEM das andere ist die CCU2 - was soll man da weiter sagen. Zwei verschiedene Dinge.
2. Was meinst Du z-Wave und Homematic? Homematic an sich?
3. Gibt es eine Lösung mit YAHM.
4. Für FHEM hast DU damit was Du brauchst.
5. Ja, aber hat mit Deiner bisherigen Fragerunde wenig zu tun. Muss eher "und" heißen ;D
6. Siehe erstens.
CCU2 könnte Homematic IP. FHEM und das Modul kann nur Homematic.
Gruß Otto
Danke für die schnelle Antwort.
Mal angenommen ich würde neben FHEM noch die OCCU SW von EQ-3 oder YAHM installieren und in FHEM dann als
define myccu HMCCU 172.0.0.1
anbinden. Dann könnte ich mit dem GPIO-Modul der CCU SW (OCCU | YAHM | piVCCU) und FHEM also HM und HM-IP?
P.S.: Z-Wave funzt. Damit kenne ich mich halbwegs aus.
Lies nochmal Deinen Satz, tritt einen Schritt zurück und entscheide dann ob das gut ist.
Ich würde das nicht tun. Ich bin zufrieden mit Homematic. Homematic IP ist für mich kein Thema und eine CCUx und HMCCU kommt mir nicht ins Haus. Ich bin ein Freund von möglichst einfachen Systemen.
FHEM ist umfangreich genug ;D
Aber es hängt ganz davon ab was man will. Was FHEM tun soll und was man für Vorlieben hat.
Gruß Otto
ich habe auch die Variante mit YAHM als virtuelle CCU2 auf dem RPi3 installiert und frage das in FHEM über HMCCU ab. Und ich muss sagen: falls du auf Homematic IP verzichten kannst dann lass es:-) Der Weg wie du ihn schon gegangen bist ist aus meiner Sicht wesentlich einfacher und du sparst dir ein System.
Zusätzlich hat die andere Variante noch den Charme, dass man zB die HM-MOD-RPI-PCB mit einem NanoCUL zusammen in FHEM in der VCCU laufen lassen kann und damit eine Redundanz erreicht. Fällt zB der NanoCUL aus übernimmt automatisch der andere.
Willst du dagegen unbedingt Homematic IP brauchst du zwingend zB YAHM und HMCCU in FHEM
Ok, vielen Dank für die Antworten.
Ich verstehe, dass der Betrieb von zwei Steuerungspaketen (FHEM für alles und zusätzlich noch mal eine OCCU) nicht das gelbe vom Ei ist. Klingt nach viel Overhead. Ich dachte lediglich, dass eQ-3 nur noch Homematic IP Geräte entwickelt und wollte dadurch sicherstellen, dass das so auch noch zukünftig läuft.
Ich werde dann erst mal mit RPI-PCB, CULv3 und VCCU rumtesten und mit Homematic Heizungsventil und Zimmer-Thermostat anfangen.
Off-Topic: Gibt es da besonders empfehlenswerte Produkte?
Danke nochmal.
Hallo mochel,
das eq3 nur noch Homematic IP entwickelt hofft keiner :-X und sieht bisher auch nicht so aus.
Von dem kann ich Dir für Homematic nur abraten -> CULv3
Homematic Heizungsventil und Zimmer-Thermostat gibt es doch eh jeweils bloß ein Produkt? ::) Was willst Du da für eine Empfehlung?
Gruß Otto
also... bei mir persönlich lief der NanoCUL (eigenbau) immer super.
Als Thermostat würde ich dir HM-CC-RT-DN empfehlen (gibt es bei ELV als Bausatz für 29,99€). Bei dem Bausatz musst du nicht mal löten.
Dazu gib es von Homematic auch Fensterkontakte (Bausatz ohne Löten bei ELV) in magnetischer und optischer Ausführung. Hab beide und hab bisher keinen großen Unterschied festgestellt. Beim Optischen hast du nur ein Teil brauchst aber eine "Gegenstelle" (z.B. weißer Rahmen).
Das ist dann schon mal recht nett: Fenster auf -> Heizung aus -> Fenster zu -> Heizung wieder an.
zusätzlich kannst du die Fensterkontakte als Schutz gegen Einbruch nutzen oder für Warnhinweise wenn man das Haus verlässt und noch ein Fenster auf hat.
Das alles ist meiner Meinung nach Starter-Level.
Zitat von: StephanFHEM am 11 Dezember 2017, 21:34:11
also... bei mir persönlich lief der NanoCUL (eigenbau) immer super.
ich habe auch mit CUL angefangen, aber spätestens wenn du versuchst, einen HM-Sen-MDIR-WM55 Bewegungsmelder anzulernen ist Schluß mit lustig. Dann brauchst du zumindest die tscul firmware, oder - noch besser - HM-MOD-RPI-PCB. Bei mir decken 2 Stk. davon Haus und Garten ab, die CULs habe ich auf signalduinos umgeflasht 8)
Vielleicht etwas OT:
Ich benutze einen nanoCUL868 V1.66 u.a. mit den HM-Sen-MDIR-WM55 und habe keine Probleme.
Hallo zusammen,
da ich mir das Homematic Funkmodul in Kürze einbaue (ersetzt den Busware-CUL-Stick), z. Zt. aber auf Pins, die die Platine (wahrscheinlich ?!) benutzen wird, einen Reset-/Reboot-/Boot-Taster habe, frage ich mal in die Runde, ob das "gutgeht"?
Dabei wird durch den Taster diese Pins gebrückt:
Pin 5 = GPIO 3 (=SCL1, I2C) und Pin 6 = GND
Dabei wird GPIO3 durch ein Script auf Input geschaltet:
#!/usr/bin/python
# shutdown/reboot(/power on) Raspberry Pi with pushbutton
import RPi.GPIO as GPIO
from subprocess import call
from datetime import datetime
import time
# pushbutton connected to this GPIO pin, using pin 5 also has the benefit of
# waking / powering up Raspberry Pi when button is pressed
shutdownPin = 3
# if button pressed for at least this long then shut down. if less then reboot.
shutdownMinSeconds = 3
# button debounce time in seconds
debounceSeconds = 0.01
GPIO.setmode(GPIO.BCM)
GPIO.setup(shutdownPin, GPIO.IN) # , pull_up_down=GPIO.PUD_UP)
buttonPressedTime = None
def buttonStateChanged(pin):
global buttonPressedTime
if not (GPIO.input(pin)):
# button is down
if buttonPressedTime is None:
buttonPressedTime = datetime.now()
else:
# button is up
if buttonPressedTime is not None:
elapsed = (datetime.now() - buttonPressedTime).total_seconds()
buttonPressedTime = None
if elapsed >= shutdownMinSeconds:
# button pressed for more than specified time, shutdown
call(['shutdown', '-h', 'now'], shell=False)
elif elapsed >= debounceSeconds:
# button pressed for a shorter time, reboot
call(['shutdown', '-r', 'now'], shell=False)
# subscribe to button presses
GPIO.add_event_detect(shutdownPin, GPIO.BOTH, callback=buttonStateChanged)
while True:
# sleep to reduce unnecessary CPU usage
time.sleep(5)
Pin5 hat nämlich, wie man im Script lesen kann, den charmanten Vorteil, auch als Boot-Button zu funktionieren.
Die Frage lautet also kurz gesagt: wird dieser GPIO von dem Modul gebraucht?
Vielen Dank und Gruß, Friedhelm
Das Funksteckmodul braucht "nur":
+3.3V (Pin 01)
GND (Pin 06 o. Pin 09 ...)
RX (Pin 10 / GPIO 15)
TX (pin 08 / GPIO 14)
Du musst halt nur sehen wie du das an den angesteckten Dingens vorbei dran kriegst...
...oder irgendwie mit "Verlängerungen"...
Alternativ: Anbindung per USB-Umsetzer (3.3V) oder WLAN (ESP8266) oder LAN (LAN-Seriell-Umsetzer)...
Gruß, Joachim
Das sind gute Nachrichten, vielen Dank Joachim!!!
Das "Dadranvorbeikriegen" werde ich dann mit zwei möglichst flachen Lötstellen an den Pins lösen.
Gruß, Friedhelm
Hallo Friedhelm,
funktioniert. Verwende ich genau so! Du kannst den Taster direkt auf die Platine löten.
Das Modul verwendet doch die ersten 12 Pins da sind die fraglichen dabei:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Gruß Otto
Danke Otto,
für die Bestätigung!
Jetzt muss ich nur noch auf's Christkind warten...
Gruß Friedhelm
So, das Christkind war da und hat das Raspberry-Pi-Funkmodul abgeliefert.
Nach dem Zusammenlöten und Installieren lt. FHEM-Wiki-Anleitung hat alles prima geklappt (Raspberry Pi 2).
Beim Vergleich der Drahtantennen meines jetzt überflüssigen CUL V3.4 und des RPI-Moduls fiel mir aber ein relativ großer Längenunterschied auf.
Lt. Wiki
https://wiki.fhem.de/wiki/CUL#Antennenl.C3.A4nge
sollte die Antennenlänge 8,6 cm sein. Selbst unter der Beachtung, dass interne Zuleitungen auch noch zählen, ist meine reine Drahtantenne - also vom Lötpunkt bis Drahtspitze - nur 7,0 cm lang. Das erscheint mir doch etwas kurz.
Wenn jemand von Euch die Antenne mal offen zugänglich hat, könnte er mal nachmessen, wie lang "seine" ist?
Zum Vergleich: Der CUL-Stick hat eine Länge von ca. 8,9 cm.
Danke Euch!
Gruß
Friedhelm
69 mm am Pi Modul
67 mm am Re-8 Modul
69 mm an der CCU1
Es gab mal diesen Artikel zum Tuning -> http://www.techwriter.de/beispiel/funkeige.htm
Gruß Otto
Vielen Dank, Otto!
Dann brauche ich keinen längeren Draht anlöten ;-)
Gruß
Friedhelm
Hallo,
im Moment nutze ich für meine Homematic devices den alten HMlan an fhem angebunden über vccu.
Um einerseits die Reichweite zu erhöhen und die Möglichkeit haben auch Homematic ip Geräte zu nutzen,
wollte ich mir jetzt das HM-MOD-RPI-PCB bestellen.
Wenn ich es richtig verstanden habe, muss das Modul nach der installation am Raspberry in fhem so definiert werden:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx
Ist es richtig, das ich als hmid, die hmid der vccu angebe und in der vccu das Modul zu attr iodevices hinzu füge?
Gruss Holgi
Zitatdie Möglichkeit haben auch Homematic ip Geräte
wo liest du denn so etwas?
nur über ccu2 oder dessen Software Emulationen!
Hm, dachte ich hätte das irgendwo gelesen.
Softwareemulation funktioniert mit dem Modul auch nicht?
Edit: Funktioniert wohl nur mit einem 2. Raspberry und
RaspberryMatic leider dann nicht mehr über vccu.
attr myHmUART hmId xxxxxx brauchst Du nicht wenn Du eine VCCU hast.
attr iodevices kenne ich bei der VCCU nicht. attr IOList wäre richtig.
guten morgen,
ich habe mir für mein Testsystem jetzt einen zweiten HM-USB besorgt.
habe ihn dann nach der Wiki Anleitung installiert, erfolglos ;)
Der HM-USB konnte nicht richtig initialisiert werden und ist ständig im 3 Sek. Takt connect/disconnect
Aber wir haben ja Otto123 ;) ;D
Bin auf seiner Seite gegangen und habe es von da nochmal installiert
und siehe da es klappt.
Fazit: Das Wiki stimmt mit Otto123 seiner Seite nicht überein, es sind unterschiede
Einen schönen Tag
Gruß Werner
Hallo Werner,
klär mich mal bitte auf, ich habe gar kein HM-USB ???
Was ist in welchem Wiki Artikel falsch?
Gruß Otto
Zitatich habe gar kein HM-USB
trotzdem so einen guten blog beitrag? respekt. 8)
@Otto123,
sorry Falschmeldung, habe jetzt beide verglichen und es passt.
Ich meinte diesen Wiki https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi)
Wie geschrieben, habe erst nach Wiki installiert, als das nicht klappte habe ich deine Anleitung genommen.
Ich denke jetzt, das ich den Fehler gemacht habe und wenn ich das aus dem Wiki vom Anfang nochmal gemacht hätte, wäre es bestimmt auch gelaufen.
Sorry
Gruß Werner
Hallo,
Modul ist installiert und funktioniert soweit, wenn ich den HMLAN vom Netzt trenne kann ich weiterhin alles schalten.
Habe es in die vccu zusammen mit meinem HMLAN eingetragen. Unter State in der vccu steht allerdings: myHmUART:UAS,HMLAN1:ok
Was hat das "UAS" zu bedeuten?
Hier mal ein list vom HM-MOD:
Internals:
AssignedPeerCnt 2
CNT 120
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 120
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 38
LastOpen 1516981240.33798
NAME myHmUART
NR 398
PARTIAL
RAWMSG 040200
RSSI -44
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
owner 29A0F1
Helper:
CreditTimer 13
FW 66561
Initialized 1
AckPending:
DBLOG:
D-HMIdAssigned:
myDbLog:
TIME 1516981245.38515
VALUE 29A0F1
D-HMIdOriginal:
myDbLog:
TIME 1516981245.41387
VALUE 59D76C
D-firmware:
myDbLog:
TIME 1516981245.44747
VALUE 1.4.1
D-serialNr:
myDbLog:
TIME 1516981245.48148
VALUE OEQ0606802
cond:
myDbLog:
TIME 1516981245.54306
VALUE ok
loadLvl:
myDbLog:
TIME 1516981245.54306
VALUE low
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
RoundTrip:
Delay 0.00302481651306152
loadLvl:
lastHistory 1516981245.51295
MatchList:
1:CUL_HM ^A......................
Peers:
19082D +19082D,00,00,00
5F8845 +5F8845,00,00,00
READINGS:
2018-01-26 16:40:45 D-HMIdAssigned 29A0F1
2018-01-26 16:40:45 D-HMIdOriginal 59D76C
2018-01-26 16:40:45 D-firmware 1.4.1
2018-01-26 16:40:45 D-serialNr OEQ0606802
2018-01-26 16:40:40 D-type HM-MOD-UART
2018-01-26 16:40:45 cond ok
2018-01-26 16:40:45 load 0
2018-01-26 16:40:45 loadLvl low
2018-01-26 16:40:40 state opened
helper:
Attributes:
hmId 29A0F1
room CUL_HM
.und von der vccu:
Internals:
DEF 29A0F1
HMLAN1_MSGCNT 3
HMLAN1_RAWMSG E29A0F1,0000,0002B5E0,FF,FFCC,97800229A0F116FC8800
HMLAN1_RSSI -52
HMLAN1_TIME 2018-01-26 16:42:56
IODev HMLAN1
LASTInputDev myHmUART
MSGCNT 21
NAME vccu
NOTIFYDEV global
NR 200
NTFY_ORDER 50-vccu
STATE myHmUART:UAS,HMLAN1:ok,
TYPE CUL_HM
assignedIOs HMLAN1,myHmUART
channel_01 vccu_Btn1
channel_02 vccu_Btn2
channel_03 vccu_Btn3
channel_04 vccu_Btn4
channel_05 vccu_Btn5
channel_06 vccu_Btn6
channel_07 vccu_Btn7
channel_08 vccu_Btn8
channel_09 vccu_Btn9
channel_0A vccu_Btn10
channel_0B vccu_Btn11
channel_0C vccu_Btn12
lastMsg No:A7 - t:02 s:29A0F1 d:339D5D 00
myHmUART_MSGCNT 18
myHmUART_RAWMSG 0500002FA7800229A0F1339D5D00
myHmUART_RSSI -47
myHmUART_TIME 2018-01-26 16:44:06
protLastRcv 2018-01-26 16:44:06
rssi_at_HMLAN1 max:-52 avg:-52 lst:-52 cnt:3 min:-52
rssi_at_myHmUART cnt:18 lst:-47 max:-46 avg:-46.05 min:-47
Helper:
DBLOG:
state:
myDbLog:
TIME 1516981243.96915
VALUE myHmUART:UAS,HMLAN1:ok,
READINGS:
2018-01-26 16:44:06 CommandAccepted yes
2018-01-26 16:40:43 state myHmUART:UAS,HMLAN1:ok,
helper:
HM_CMDNR 167
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1516981446.41459
prefIO
vccu
ioList:
HMLAN1
mRssi:
mNo A7
io:
myHmUART -47
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_HMLAN1:
avg -52
cnt 3
lst -52
max -52
min -52
at_myHmUART:
avg -46.0555555555556
cnt 18
lst -47
max -46
min -47
tmpl:
Attributes:
IODev HMLAN1
IOList HMLAN1,myHMUART
expert 2_full
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
Hoffe jemand kann mir weiter helfen.
Gruß Holgi
Fällt Dir was auf!?
STATE myH
mUART:UAS,HMLAN1:ok,
IOList HMLAN1,myH
MUART
ZitatWas hat das "UAS" zu bedeuten?
Heisst wohl: unassigend
Gruß Otto
Au nein! Ich trottel, danke für den Hinweis.
Noch eine Frage: Habe in allen devices als IOgrp vccu angegeben, wenn ich es richtig verstanden habe regelt die vccu so selbst, welches io Gerät benutzt wird abhängig
von der Signalstärke, oder?
Gruß Holgi
so sollte es sein ;)
Hallo Freunde,
ich habe bis dato einen HM-CFG-LAN LAN Konfigurations-Adapter unter FHEM auf einem PI im Einsatz.
Ich möchte mir gerne eine Redundanz/Ausfall-Sicherheit schaffen. Statt nun einen zweiten HM-CFG-LAN LAN Konfigurations-Adapter zum Einsatz zu bringen, denke ich darüber nach, nun statt dessen das "neue" HM-LGW-O-TW-W-EU Funk-LAN Gateway einzusetzen.
Meine Frage nun:
Kann ich statt zwei HM-CFG-LAN LAN Konfigurations-Adapter parallel auch einen HM-CFG-LAN LAN Konfigurations-Adapter und ein HM-LGW-O-TW-W-EU Funk-LAN Gateway einsetzen, so dass alle Homematic-Komponenten von beiden Gateways angesprochen werden?
Mit zwei HM-CFG-LAN LAN geht das ja wohl.
Ich würde mich über eine Rückmeldung sehr freuen.
Vielen Dank und Gruß
Christian
Hallo Christian,
das geht, Du brauchst eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU).
Welche konkreten HM IOs Du darin gruppierst ist egal.
Gruß Otto
Hallo Otto,
danke für die schnelle Rückmeldung.
Bis dato habe ich eine VCCU im Einsatz um herrenlose Komponenten, die per autocreate erkannt werden und nicht auf meinem Gebäude stammen, dort "zu sammeln".
Dazu läuft die VCCU bis jetzt unter der ID des HMLANs.
Dann muss ich das umbauen und dem VCCU eine eigene ID geben oder nur noch die ID des HMLANs, damit das Pairing der Komponenten weiter klappt.
Den HMLAN hänge ich dann unter die VCCU mit neuer ID?
Gruß
Christian
NEIN!
Du musst nichts umbauen.
ZitatDazu läuft die VCCU bis jetzt unter der ID des HMLANs.
Mag sein, dass Du das so siehst, es ist aber genau anders herum.
Die VCCU gibt die ID (auch wenn die mal dem HMLAN gehörte) an alle unter ihr gruppierten IOs.
Alles gut so, es muss so sein. Du musst Deine ID behalten sonst müsstest Du alles neu machen.
Gruß Otto
ok, hört sich gut an.
Bis jetzt sieht meine VCCU-Config so aus:
defmod vccu CUL_HM 37A0AF
attr vccu IODev HMLAN1
attr vccu IOList HMLAN1
attr vccu model CCU-FHEM
attr vccu room Zentral
attr vccu subType virtual
attr vccu webCmd virtual:update
setstate vccu HMLAN1:ok,
setstate vccu 2018-03-11 13:41:32 state HMLAN1:ok,
setstate vccu 2018-03-13 19:11:21 unknown_24E293 received
setstate vccu 2018-03-13 19:11:07 unknown_4C59A6 received
setstate vccu 2018-03-13 19:11:07 unknown_4C5A27 received
setstate vccu 2018-03-11 14:09:07 unknown_597E7B received
setstate vccu 2018-03-12 19:44:51 unknown_5BC6B1 received
setstate vccu 2018-03-11 14:12:35 unknown_6464D0 received
37A0AF ist die ID des HMLAN.
Die "unknown"-Einträge fangen ja bewusst die unbekannten Komponenten aus dem autocreate ab, die nicht mir "gehören".
und hier die Definition des HMLANs:
defmod HMLAN1 HMLAN 192.168.10.66:1000
attr HMLAN1 hmId 37A0AF
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room Zentral
setstate HMLAN1 opened
setstate HMLAN1 2018-01-30 09:04:33 D-HMIdAssigned 37A0AF
setstate HMLAN1 2018-01-30 09:04:33 D-HMIdOriginal 37A0AF
setstate HMLAN1 2018-01-30 09:04:33 D-firmware 0.964
setstate HMLAN1 2018-01-30 09:04:33 D-serialNr MEQxyzxyz
setstate HMLAN1 2018-03-11 13:41:32 Xmit-Events disconnected:12 ok:12 Warning-HighLoad:1 init:11
setstate HMLAN1 2018-03-11 13:41:32 cond ok
setstate HMLAN1 2018-03-14 16:01:49 loadLvl low
setstate HMLAN1 2018-03-11 13:41:21 prot_Warning-HighLoad last
setstate HMLAN1 2018-03-09 09:05:12 prot_disconnected last
setstate HMLAN1 2018-03-09 09:05:12 prot_init last
setstate HMLAN1 2018-03-05 16:45:30 prot_keepAlive last
setstate HMLAN1 2018-03-11 13:41:32 prot_ok last
setstate HMLAN1 2017-03-11 10:37:24 prot_timeout last
setstate HMLAN1 2018-03-09 09:05:12 state opened
Ist das dann soweit richtig?
Wenn ich mein neues Gateway habe, richte ich das mit der alten ID erst mal selbst ein und hänge es dann in der VCCU-Definition an die IO-Liste.
Also überall (VCCU, HMLAN und HMLAN<Neu>) wir die gleiche ID eingesetzt?!
Gruß
Christian
Du richtest das neue Gateway ein, HMId brauchst Du gar nicht, macht später die VCCU
Du änderst in der VCCU das attr IOList
Das war es, alles andere sollte automatisch passieren.
Das attr IOgrp bei deinen HM Komponenten hast Du schon gesetzt?
Gruß Otto
hier einmal ein Auszug:
attr Ku.Fenster.Contact.Links IODev HMLAN1
attr Ku.Fenster.Contact.Links IOgrp vccu:HMLAN1
wobei
attr Ku.Fenster.Contact.Links IOgrp vccu:HMLAN1
anscheinend nicht überall gesetzt ist.
Das geschah wohl stellenweise "automatisch"....
@cseuss
setstate HMLAN1 2018-01-30 09:04:33 D-firmware 0.964
mach mal dringend ein Update des Hmlans auf 0.965
sonst rebootet er bei Empfang von HMIP Messages , die Firmware gibts bestimmt schon seit 2,5 Jahren !
Hallo,
Ok. Firmware-Update auf dem HLAN ist eingespielt.
Könnt Ihr noch auf den Beitrag #205 eingehen?
Muss ich das Attribut dann noch bei allen Komponenten setzen?
Danke für Eure Rückmeldung.
Gruß
Christian
Hallo Christian,
naja stand doch im Prinzip in #204 ;)
IOgrp vccu sollte überall gesetzt sein. mit deinem Zusatz :HMLAN1 wäre der dann bevorzugt.
Das attr wird von der VCCU automatisch gesetzt wenn das Gerät mit der VCCU gepairt wird.
Für alle Alten musst Du es setze.
Damit würde es automatisch gehen:
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
Aber das würde Deine gesetzten mit bevorzugtem IO überschreiben!
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#IOgrp_bei_nachtr.C3.A4glicher_Einrichtung_einer_VCCU
Gruß Otto
Danke für die Rückmeldung.
Nun ist mein neues LAN-Gateway heute angekommen und ich habe nun die nachfolgende Config:
define HMLAN1 HMLAN 192.168.10.66:1000
attr HMLAN1 hmId 37A0AF
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room Zentral
define HMLANGWOG HMUARTLGW 192.168.10.36
attr HMLANGWOG hmId 37A0AF
attr HMLANGWOG lgwPw def6h+wS7S
attr HMLANGWOG room Zentral
define VCCU CUL_HM 37A0AF
attr VCCU IODev HMLAN1
attr VCCU IOList HMLAN1,HMLANGWOG
attr VCCU model CCU-FHEM
attr VCCU room Zentral
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Danach kommen die HM-Devices:
Beispiel:
define Bd.Heizung.Wand CUL_HM 3098E2
attr Bd.Heizung.Wand IODev HMLAN1
attr Bd.Heizung.Wand IOgrp VCCU
Passt das jetzt so?
Ist es richtig, dass die HM-Devices und die VCCU das Attribut: "IODev HMLAN1" haben?
Vielen Dank für Eure Unterstützung.
Gruß
Christian
Hi,
das attr IODev spielt keine Rolle mehr wenn die VCCU die Verwaltung übernimmt. Sie setzt das dynamisch.
Gruß Otto
Ich habe folgendes Problem mit diesem Modul:
Modul steckt auf Raspberry Pi 3
Die Konfiguration des Systems und das Aufspielen von FHEM erfolgte gemäß Wiki Eintrag.
Danach ging es gemäß https://forum.fhem.de/index.php/topic,54511.0.html
sowie dem Beitrag von betateilchen weiter.
Abschließend erfolgte die Einbindung des Moduls gemäß https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Nun steht im Log folgendes:
2020.05.04 14:46:53 1: Including fhem.cfg
2020.05.04 14:46:54 3: WEB: port 8083 opened
2020.05.04 14:46:54 2: eventTypes: loaded 69 events from ./log/eventTypes.txt
2020.05.04 14:46:59 1: Including ./log/fhem.save
2020.05.04 14:46:59 3: Opening myHmUART device /dev/ttyAMA0
2020.05.04 14:46:59 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.05.04 14:46:59 3: myHmUART device opened
2020.05.04 14:46:59 0: Featurelevel: 6
2020.05.04 14:46:59 0: Server started with 20 defined entities (fhem.pl:21762/2020-04-23 perl:5.028001 os:linux user:fhem pid:484)
2020.05.04 14:47:10 3: myHmUART: Unknown code A0CD7867016F83600000000923D::-76:myHmUART, help me!
2020.05.04 14:49:53 3: myHmUART: Unknown code A0CD8867016F83600000000923C::-79:myHmUART, help me!
2020.05.04 14:52:22 3: myHmUART: Unknown code A0CD9867016F83600000000923C::-77:myHmUART, help me!
2020.05.04 14:54:37 3: myHmUART: Unknown code A0CDA867016F83600000000923D::-76:myHmUART, help me!
2020.05.04 14:56:37 3: myHmUART: Unknown code A0CDB867016F83600000000923D::-75:myHmUART, help me!
2020.05.04 14:59:27 3: myHmUART: Unknown code A0CDC867016F83600000000933D::-79:myHmUART, help me!
2020.05.04 15:02:03 3: myHmUART: Unknown code A0CDD867016F83600000000943D::-77:myHmUART, help me!
Was ist hier nicht in Ordnung?
Ist alles in Ordnung...
Man sieht das Modul empfängt...
...kann aber mit den Daten nichts anfangen...
Sieht aber nach HomeMatic IP aus!?
Sind das evtl. deine Sensoren/Aktoren!?
Wenn ja und wenn HomeMatic IP, dann nehme ich "alles in Ordnung" zurück...
Das Funkmodul kann nur HomeMatic "Classic"/BidCos (soweit ich weiß)...
...bzw. so wie es eingebunden ist auf alle Fälle!
Wenn es nicht deine sind, dann vom Nachbarn...
Mal im Forum suchen, wird immer wieder gefragt und auch beantwortet... ;)
Eine vccu hilft hier aber (meines Wissens) nicht...
Aber eine zu haben ist trotzdem ratsam...
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Gruß, Joachim
kein "corona", alles gut. ;)
wenn 16F836 dein device (tempsensor oder thermostat) ist, würde ich es mal pairen.
mit der empfholenen vccu hättest du die infos erst gar nicht gesehen.
Hmm, Mist...
Ich dachte die A-Meldungen sind HomeMatic IP...
Wie sehen denn die aus!?
EDIT: Pairen findest du hier https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen und nat. jeweils in der BA des Gerätes -> verbinden mit Zentrale...
Gruß, Joachim
A... ist bei bidcos und hmip.
hmip ist meistens länger und der inhalt ist für mich nicht als bidcos zu erkennen. ausschlussverfahren. ;)
A06... ist immer hmip.
ok, DANKE!
Gruß, Joachim
Danke für die Antworten.
Momentan sind nur 4 Tempsensoren und das Funkmodul am Raspberry.
Die Sensoren laufen über 1 Wire und sind ohne Probleme im FHEM integriert.
Auch die graphische Auswertung läuft.
Bis jetzt habe ich nur das Modul in Betrieb genommen. Das zugehörige Thermostat ist noch nicht in Betrieb. War bei Anlieferung leider defekt.
Daher habe ich nichts zum pairen.
Es sind keine HM Ip Module im Spiel und auch keine solchen in der Umgebung.
Hallo.
Da mein HM-CFG-LAN den geist aufgab, habe ich mir jetzt HM-MOD-RPI-PCB besorgt u. eingebunden.
Aber das ding startet alle 12sec. neu. Auch pairen klappt nicht.
gelöst -> https://forum.fhem.de/index.php/topic,54511.msg460972.html#msg460972
Das Device läuft bisher gar nicht ;)
1. https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
2. https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_an_die_GPIO_im_Raspberry
Hast Du da alle Hinweise beachtet?
danke, gelöst -> https://forum.fhem.de/index.php/topic,54511.msg460972.html#msg460972
Hallo zusammen,
ich hatte am Wochenende einen kurzen Stromausfall, seitdem war einer meiner HM-MOD-RPI-PCB UARTs auf Raspi nicht mehr erreichbar. Mein erster Verdacht am Raspi richtet sich immer auf die SD-Karte. Also neue Karte hergenommen, Backup drauf und reingesteckt. Ich mache zum Glück regelmäßig dd-Backups. Leider brachten die letzten drei Backups (jeweils eine Woche Abstand) das Ding nicht mehr an's Rennen, obwohl er laut fhem-log zu diesen Zeitpunkten noch lief. Ich habe dann ein aktuelles Raspbian Bullseye geflasht und zuerst socat installiert, damit lief dieser UART bisher. Der Service auf dem Raspi läuft, der Port steht auf "LISTEN" aber in fhem toggelt das device zwischen init und disconnected. Ich habe dann mal ser2net installiert (socat natürlich deaktiviert), auch damit keine Chance.
Dann habe ich mir zwei neue HM-MOD-RPI-PCB bestellt und installiert, vielleicht hat der Alte - wie auch immer- beim Stromausfall einen weg gekriegt. Immer noch nix -> init <-> disconnected.
Dann habe ich schließlich ein altes Raspbian Buster runtergeladen, auf die Karte gepackt, socat installiert .... und FLUPP - läuft - auch der alte UART. ::)
Ich habe bisher nichts gefunden, was darauf hindeutet, daß fhem nicht mit einem seriell-to-net Dienst unter Raspbian Bullseye verbinden kann. Vielleicht findet das jemand raus, der tiefer drin steckt. Falls jemand auf ein ähnliches Problem stößt: RaspBian BullsEye meiden.
Gruß Roland
Könnte man im Wiki-Eintrag https://forum.fhem.de/index.php?topic=88047.0
vielleicht noch mit aufnehmen, dass wenn man TX und RX direkt an einen C2102 anlötet (ohne die Aufsteck-Zwischenplatine für den RPI),
es dann evtl. funktioniert? Da scheint das Signal noch durch Widerstände gedämpft zu sein.
Mich hat es Stunden gekostet, das herauszufinden.
fehlende/falsche pegelanpassung?
in dem verlinkten Thread war doch aber das eigentliche Problem der fehlerhafte CP2102 ? So lese ich das zumindest. Und der Hinweis ist im Wiki.
Ich habe mehrfach die Originalvariante mit USB Adapter im Einsatz und das läuft. Ich denke eher es kann auch mal nicht laufen wenn man die Widerstände weglässt.
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. Mein erster Verdacht am Raspi richtet sich immer auf die SD-Karte. ...
Hallo nochmal,
ich wollte meinen Beitrag ergänzen. Seit dem erwähnten Stromausfall ärgert mich der UART. Nachdem er wieder ein paar Tage lief, konnte fhem wieder nicht mehr verbinden (... did not respond...). Der Service läuft, der Raspi ist erreichbar. Ich habe den Raspi jetzt mal an einen anderen Switch gesteckt. Da hat fhem sofort connecten können, vielleicht auch wegen des Neustarts. Ich hatte vor einiger Zeit mal einen (Consumer-)Switch, der nach einigen Jahren sporadisch immer wieder mal schwer nachvollziehbare Probleme gemacht hat.
Ich werde das ein paar Tage beobachten. Falls es wieder zuverlässig funktionieren sollte, würde ich empfehlen, bei sporadischen Problemen auch mal das Netz drumherum in den Kreis der Verdächtigen aufzunehmen. Falls ich auf dem Holzweg war, werde ich auch das berichten.
Gruß Roland
Update:
Der UART-Raspi hängt jetzt seit 9 Tagen an einem anderen Switch. Seither ist er noch nicht wieder ausgestiegen. Damit steigt die Wahrscheinlichkeit, daß der Switch, wo er vorher dran war, seit dem Stromausfall doch eine Macke hat, zumindest an diesem Port, wo der Raspi vorher angeschlossen war. Ich werde den Raspi zum Gegencheck jetzt auch nicht mehr zurück stecken. Funktechnisch ist der neue Standort auch gut und ich bin froh, daß alles wieder sauber läuft.
Wie schon festgestellt, schadet es also nicht, bei solchen Problemen auch das LAN mit in Betracht zu ziehen.
Gruß Roland
Mist. Ich habe mich zu früh gefreut. Seit heute pendelt der UART in fhem wieder zwischen init und disconnected mit "... did not respond" im Log. Raspi rebootet, fhem neu gestartet, fhem-NUC rebootet, keine Chance. Der socat service am Raspi läuft, aber fhem kriegt keinen connect mehr hin. So langsam gehen mir die Ideen aus - und heute habe ich auch keinen Bock mehr. Ich habe zum Glück noch drei weitere UARTS laufen mit etwas schlechterem RSSI, aber es geht. Den vierten habe ich erst kürzlich aufgebaut, als wenn ich's geahnt hätte. ;D
Morgen kuck' ich mal genauer hin. Wie könnte man denn von der fhem-Maschine aus manuell testen, ob der Port am Raspi Verbindungen annimmt? Blöde Frage, es war wohl stressig heute...
Gruß Roland
Ich habe den socat Port tcp/4000 mal in mein checkmk mit aufgenommen. Der ist kontinuierlich erreichbar. Am Raspi/UART selbst scheint es nicht zu liegen. Ich kann auch vom NUC aus (auf dem fhem läuft) mit "telnet <remotehost> 4000" eine Verbindung aufbauen.
Service auf raspiuart2 vor der telnet Verbindung:
roland@raspiuart2:~ $ sudo systemctl status hmlangw
● hmlangw.service
Loaded: loaded (/etc/systemd/system/hmlangw.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2023-04-13 08:59:10 CEST; 4s ago
Main PID: 16675 (socat)
Tasks: 1 (limit: 2200)
Memory: 312.0K
CGroup: /system.slice/hmlangw.service
└─16675 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
Apr 13 08:59:10 raspiuart2 systemd[1]: Started hmlangw.service.
Dann telnet auf fhem-NUC:
roland@fhem:~$ telnet raspiuart2 4000
Trying 192.168.1.87...
Connected to raspiuart2.zero.local.
Escape character is '^]'.
▒s*▒.f▒
▒▒@▒▒$tW▒l▒▒▒▒▒:▒7▒p▒8▒_2▒▒n▒
▒PM&▒▒uH▒▒▒▒l▒▒sUL▒'▒▒O}▒▒▒v>▒▒^,▒▒▒▒}▒▒▒w"▒<▒
▒▒
@▒▒▒x2▒V▒f
▒▒@▒=▒yR▒▒"▒▒
▒▒@▒▒PuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTY▒z<`▒,R!'PuTTY-▒▒▒▒▒{=▒▒Z'▒PuTTY▒▒Bϋ
Daß da nur wilder ASCII Salat zurückkommt, ist normal, denke ich.
Service auf raspiuart2 während der telnet session:
roland@raspiuart2:~ $ sudo systemctl status hmlangw
● hmlangw.service
Loaded: loaded (/etc/systemd/system/hmlangw.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2023-04-13 08:59:10 CEST; 5min ago
Main PID: 16675 (socat)
Tasks: 2 (limit: 2200)
Memory: 520.0K
CGroup: /system.slice/hmlangw.service
├─16675 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
└─17348 /usr/bin/socat TCP4-LISTEN:4000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
Apr 13 08:59:10 raspiuart2 systemd[1]: Started hmlangw.service.
Technisch scheint es also zu funktionieren, nur fhem kriegt keine Connection hin, pendelt permanent zwischen init und disconnected. Im fhem Log sehe ich nur:
2023.04.13 09:10:45.953 3: Opening HmUART2 device 192.168.1.87:4000
2023.04.13 09:10:45.971 3: HmUART2 device opened
2023.04.13 09:10:49.978 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:10:53.012 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:10:56.018 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:10:59.026 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:10:59.029 3: HmUART2 device closed
2023.04.13 09:10:59.078 1: 192.168.1.87:4000 reappeared (HmUART2)
2023.04.13 09:11:03.083 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:11:06.521 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:11:09.611 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:11:12.707 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:11:12.711 3: HmUART2 device closed
2023.04.13 09:11:13.087 1: 192.168.1.87:4000 reappeared (HmUART2)
2023.04.13 09:11:17.090 1: HMUARTLGW HmUART2 did not respond for the 1. time, resending
2023.04.13 09:11:20.097 1: HMUARTLGW HmUART2 did not respond for the 2. time, resending
2023.04.13 09:11:23.102 1: HMUARTLGW HmUART2 did not respond for the 3. time, resending
2023.04.13 09:11:26.107 1: HMUARTLGW HmUART2 did not respond after all, reopening
2023.04.13 09:11:26.111 3: HmUART2 device closed
Hat vielleicht jemand noch eine Idee? Die anderen drei UARTS laufen problemlos, da kann auch fhem ohne Problem verbinden. Ich habe auch schon ser2net auf dem raspiuart2 getestet, bin aber wieder zurück auf socat, weil das erstens das Problem nicht behebt und zweitens, weil mir die neumodische YAML Konfiguration zu zickig ist. Da muß nur eine Zeilen-Einrückung nicht stimmen, schon haut der Dir das Ding um die Ohren.
Gruß Roland
Ich werde da irgendwie nicht schlau draus :( ::)
Ich habe das fhem device mal gelöscht und neu angelegt - keine Änderung.
Dann habe ich den Raspi stromlos gemacht und auf einen anderen freien Port am Switch gesteckt. Das war dumm, ich hätte nur EINE Änderung machen sollen. Das kommt dann beim nächsten Mal.
Jetzt geht's wieder. Fhem Device "set HmUART2 open" - flupp "open" und alles gut, als wäre nie was gewesen.
Ich habe keine konkrete Idee, wo es klemmen könnte. Der Raspi ist im LAN verfügbar, keine Paketverluste, nix. Der Port 4000 ist von außen erreichbar und antwortet. Das Netzteil - auch ein häufiger Kandidat für Probleme - ist ein original Raspi Netzteil. Das Einzige, was ich beim nächsten Ausfall noch ergänze, ist der Ferritkern am Stromversorgungskabel, den habe ich vergessen. Wobei alle anderen UART Raspis auch ohne den Kern auskommen und keine Probleme machen.
Die SD-Karte ist auch neu. Wenn die Raspis nicht so unverschämt teuer und auch verfügbar wären, würde ich alles komplett neu aufsetzen und daneben hinstecken. Einen UART Bausatz habe ich noch liegen.
Gruß Roland
vielleicht läuft ser2net stabiler?
Der nächste Versuch kam schneller als gedacht :)
Ich mußte einmal reopen machen, weil ich bei der Neuanlage des fhem-Devices den hmKey vergessen hatte. Und schon gingen die erfolglosen reconnect Versuche wieder los. Diesmal war ich wenigstens so schlau und habe nur die Stromversorgung am Raspi abgezogen. Danach ging's wieder.
Ich werde mir also doch mal ein neues Raspi Netzteil besorgen. Die sind auch nicht gerade für Langlebigkeit bekannt und ein kurzer Stromausfall kann da wohl auch einen Schaden hinterlassen, besonders, wenn nach einer FI-Auslösung alle Geräte plötzlich wieder Strom kriegen. Vielleicht entstehen da Spannungsspitzen im Netz, die die Schaltnetzteile nicht vertragen.
Gruß Roland
Zitat von: frank am 13 April 2023, 13:19:19vielleicht läuft ser2net stabiler?
Ser2net hatte ich auf diesem Raspi auch schon getestet: mit den gleichen Effekten. Ich habe auch zwei Raspis, wo der UART über ser2net mit der alten Konfiguration läuft. Mich stört aber die eingeführte zickige YAML Konfiguration. Der kleinste Fehler beim Zeilen-Einrücken wird völlig intolerant abgewiesen. Nur Leerzeichen, keine Tabs... einfach nervig.
Gruß Roland
Du kannst doch mit vcgencmd get_throttled prüfen, ob es Unterspannung gibt/gab.
Und wichtig ist (auch) Spannung!
Es sollten/müssen 5,1-5,2V sein...
Ich hatte auch das Phänomen, dass ein Netzteil wohl die Spannung nicht mehr ausreichend geliefert hat.
Hab jetzt schon bei 2 PIs ein Step-Up dazwischen gehangen.
Hatte Probleme mit meinem RaspBee...
Danach/seit dem ist Ruhe :)
Gruß, Joachim
Das kannte ich noch nicht. Da kommt bei mir:
roland@raspiuart2:~ $ sudo vcgencmd get_throttled
throttled=0x0
roland@raspiuart2:~ $Muß das nach einem Neustart erst noch Daten sammeln? 0x0 heißt wohl "alles gut", wie hier beschrieben (https://forum.libreelec.tv/thread/17860-how-to-interpret-rpi-vcgencmd-get-throttled/).
Brauchen die Step-Up nicht mehr Spannungsdifferenz zwischen in und out? Ich bin da nicht so sattelfest. :(
Gruß Roland
0x0 passt.
Es gibt ja 2 Dinge: "aktuelle Störung" und "Störung trat schon mal auf"
Ich frage das regelmäßig per Script ab und setze Readings...
Hmmm, den Step-up (die ich verwende) ist es (wohl) egal.
Step-down ist (wohl) anders, da muss Eingang (immer deutlich) höher sein als Ausgang...
Scheint bei dir aber wohl nicht das Problem zu sein, wenn es bei 0x0 bleibt...
Gruß, Joachim
So langsam nervt mich der Raspi mit dem HmUART. Der geht nach einer unbestimmten Zeitspanne immer wieder auf disconnected/init - und auch nur einer von Vieren - Es ist kein Muster erkennbar, wieviel Zeit dazwischen liegt. Ich habe jetzt erstmal einen Funkschalter dazwischen, mit dem ich den Raspi ausknipsen kann, wenn er auf cond != ok geht. Eine Lösung ist das natürlich nicht, ich werde mir aber auf keinen Fall einen Raspi3 für 120€ oder noch mehr kaufen zum Testen. Im Wiki bin ich gerade nochmal (wieder ::) ) auf den möglichen Betrieb mit einem ESP8266 gestoßen. WLAN ist jetzt nicht meine bevorzugte Technik zum Vernetzen, zumal die 8266 gerne mal unter WLAN Schluckauf leiden. Aber zuverlässiger als ein im Minuten-/Stunden-/oder Tagestakt unterbrochener Raspi mit UART wird es allemal sein. Und ein paar Wemos Mini und D1 Boards habe ich rumliegen. Jetzt ärgere ich mich nur, daß ich nicht früher wieder drauf gekommen bin.
Gruß Roland
Hi
Die Idee den Raspi per StromAus hart auszuschalten ist vielleicht nicht so gut.
Ich hätte da die Befürchtung, dass früher oder später der Datenträger (SD Karte?) hin ist. Oder zumindest das Dateisystem Schaden nimmt.
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.
Irgendwas muß ich übersehen. Vielleicht muß ich den Kram mal ein paar Tage liegen lassen.
Dummerweise kann ich seit ein paar Wochen fhem nicht mehr updaten. Nach dem Update startet fhem nicht mehr, es kommt nicht mehr über die JeeLink Initialisierung hinweg, auch wenn ich den vor dem Update disable. Die letzten drei Versuche mußte ich aus dem restoreDir wiederherstellen, daß fhem wieder hochkommt. Aber das gehört nicht hierher, ich habe das aber in dem Zusammenhang hier zu aktualisieren versucht. Die ganzen Jahre vorher hatte ich mit dem Update nie Probleme.
Irgendwann muß ich da mal ran, schon wegen Ubuntu 16.04. Aber der ganze Kram drumrum mit Mosquitto, die ganzen über die Jahre nachinstallierten Perl-Module usw. - das alles wieder hinkriegen, da brauche ich Urlaub.
Gruß Roland
Zitat von: RalfRog am 14 April 2023, 14:25:01Hi
Die Idee den Raspi per StromAus hart auszuschalten ist vielleicht nicht so gut.
Ich hätte da die Befürchtung, dass früher oder später der Datenträger (SD Karte?) hin ist. Oder zumindest das Dateisystem Schaden nimmt.
Ich weiß, das ist nur ein Strohhalm, bis ich eine richtige Lösung habe. Aber die ESP8266-Geschichte ist wohl auch gestorben, siehe einen Beitrag drüber. >:( :'(
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.
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
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.
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
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
Zitat von: hauwech am 15 April 2023, 20:01:22Alternativen zum ehemaligen HM-config-LAN?
den neuen eckigen ;)
https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
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.
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
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
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. ...
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
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
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
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 (https://forum.fhem.de/index.php/topic,125817.msg1233521.html)
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
Hallo Reiner,
die Firmware ist wirklich da?
{qx(ls -lha ./FHEM/firmware)}Den Hinweis hast Du mal probiert?
ZitatSollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!
Zitat von: Otto123 am 08 Juli 2023, 13:50:57die Firmware ist wirklich da?
{qx(ls -lha ./FHEM/firmware)}
insgesamt 4,0M
drwxr-xr-x 2 fhem dialout 4,0K 10. Sep 2022 .
drwxr-xr-x 6 fhem dialout 28K 2. Jun 18:29 ..
-rw-r--r-- 1 fhem dialout 91K 17. Jun 2020 ArduCounter.cpp
-rw-r--r-- 1 fhem dialout 844K 17. Jun 2020 ArduCounter-ESP32.bin
-rw-r--r-- 1 fhem dialout 8,0K 17. Jun 2020 ArduCounter-ESP32-boot_app0.bin
-rw-r--r-- 1 fhem dialout 16K 17. Jun 2020 ArduCounter-ESP32-bootloader_dio_40m.bin
-rw-r--r-- 1 fhem dialout 3,0K 17. Jun 2020 ArduCounter-ESP32-partitions.bin
-rw-r--r-- 1 fhem dialout 897K 17. Jun 2020 ArduCounter-ESP32T.bin
-rw-r--r-- 1 fhem dialout 382K 14. Jan 21:22 ArduCounter-ESP8266.bin
-rw-r--r-- 1 fhem dialout 42K 20. Sep 2019 ArduCounter.hex
-rw-r--r-- 1 fhem dialout 45K 17. Jun 2020 ArduCounter-NANO.hex
-rw-r--r-- 1 fhem dialout 2,4K 17. Jun 2020 ArduCounter-platformio-sample.ini
-rwxr-x--- 1 fhem dialout 87K 8. Jul 11:54 coprocessor_update.eq3
-rw-r--r-- 1 fhem dialout 97K 5. Apr 2017 esptool.py
-rwxr--r-- 1 fhem dialout 133K 4. Okt 2017 hm_cc_rt_dn_update_V1_5_003_171004.eq3
-rwxrwxrwx 1 fhem root 113K 12. Aug 2015 HM-ES-PMSw1-Pl_update_V2_6_0000_150812.eq3
-rwxr--r-- 1 fhem dialout 138K 12. Dez 2016 HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
-rwxr--r-- 1 fhem dialout 122K 10. Feb 2017 hm_tc_it_wm_w_eu_update_V1_4_002_170213.eq3
-rw-r--r-- 1 fhem dialout 54K 2. Jul 2016 JeeLink_EC3000.hex
-rw-r--r-- 1 fhem dialout 508K 20. Sep 2019 JeeLink_LaCrosseGateway.bin
-rw-r--r-- 1 fhem dialout 76K 5. Apr 2017 JeeLink_LaCrosse.hex
-rw-r--r-- 1 fhem dialout 34K 2. Jul 2016 JeeLink_PCA301.hex
-rw-r--r-- 1 fhem dialout 68K 10. Sep 2022 SIGNALDuino_miniculcc1101_3.5.0.hex
-rw-r--r-- 1 fhem dialout 49K 5. Apr 2017 SIGNALduino_nano328.hex
-rw-r--r-- 1 fhem dialout 49K 5. Apr 2017 SIGNALduino_promini328.hex
-rw-r--r-- 1 fhem dialout 49K 5. Apr 2017 SIGNALduino_uno.hexZitatDen Hinweis hast Du mal probiert?
ZitatSollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!
Ja, ist bei dem Olimex Board dank PoE ja durch ziehen des Lan-Kabels recht einfach.
zumindest Die Firmwaredatei sieht gut aus, Größe ist bei mir auch 87k.
Tja keine Idee. Ich glaube ich habe meine Module alle alle lokal geflashed.
Hast Du einen USB / seriell Wandler und kannst ihn umstecken? Brauchst dazu ja nur 4 Kabel.
-rwxr-x--- 1 fhem dialout 87K 8. Jul 11:54 coprocessor_update.eq3
bist du sicher das deine Rechte stimmen?
Zitat von: LuckyDay am 08 Juli 2023, 16:24:01-rwxr-x---
das x ist unnütz aber nicht schädlich. Es reicht ja wenn user fhem lesen kann.
Zitat von: Otto123 am 08 Juli 2023, 16:21:47Hast Du einen USB / seriell Wandler und kannst ihn umstecken? Brauchst dazu ja nur 4 Kabel.
Ja, so habe ich das jetzt gemacht und hat auch auf Anhieb geklappt. Danke! Jetzt ist die 1.4.1 drauf. Integration in die VCCU hat auch geklappt und jetzt brauche ich nur noch ein wohnzimmertaugliches Gehäuse für die Kombination, vielleicht bekomme ich ja alles sogar in das Gehäuse des defekte HM-CFG-LAN rein :)
Hallo,
ich habe mich in den letzten Tag massiv durch das Wiki und das Forum gekämpft aber leider keine Lösung für mein Problem gefunden.
Ich bekomme bei meinem HM-MOD-RPI-PCB auch immer wieder die Reconnects. Allerdings sind bei mir die Rahmenbedingungen etwas anders.
Aktuell verwende ich einen RPi3 mit dem Homematic LAN Gatway eQ3-HM-LGW.
Da es bei der Konfiguration leider immer wieder zu Reconnectes kommt wodurch generell FHEM hin und wieder einfriert, möchte ich umsteigen.
Dazu hab ich mir einen RPi5 zugelegt und das HM-MOD-UART nach der Anleitung zusammengelötet.
siehe beigefügtes Bild
IMG_5479.jpg
Unter Debian GNU/Linux 12 (bookworm) und auf dem RPi5 dürfte der default Port nun statt ttyAMA0 der ttyAMA10 sein.
Deswegen habe ich das Gerät auch so eingebunden :
define myHmUART HMUARTLGW /dev/ttyAMA10
attr myHmUART group HomeMatic
attr myHmUART hmId AA12BD
attr myHmUART logIDs sys,all
attr myHmUART room Transmitter
In der FHEM Config sind die Werte :
attr global mseclog 1
attr initialUsbCheck disable 1
gesetzt.
Linux Version
uname -a :
Linux DerGerät 6.1.74-v8-16k+ #1 SMP PREEMPT Fri Jan 26 12:14:39 UTC 2024 aarch64 GNU/Linux
Was hab ich im Linux gemacht :
config.txt - Am Ende eingefügt
[all]
enable_uart=1
force_turbo=1
dtoverlay=miniuart-bt
core_freq=250
cmdline.txt
console=tty1 root=PARTUUID=2ee9318e-02 rootfstype=ext4 fsck.repair=yes rootwait
Folgende Ausgaben :
ls -l /dev/tty
crw-rw-rw- 1 root tty 5, 0 29. Jän 15:05 /dev/tty
ls -l /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 74 29. Jän 15:05 /dev/ttyAMA10
ls -l /dev/serial*
lrwxrwxrwx 1 root root 8 29. Jän 14:11 /dev/serial0 -> ttyAMA10
groups fhem
fhem : dialout tty
Die Commands hab ich auch ausgeführt
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
Leider verliert das Modul immer wieder die Verbindung, auch ein Firmwareupdate scheint nicht zu klappen.
In FHEM bekomm ich gar keine Meldung mit
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3und in Linux mit
systemctl stop fhem
./flash-hmmoduart -U /dev/ttyAMA10 coprocessor_update.eq3
HM-MOD-UART flasher version 0.103-git
Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.
Initializing HM-MOD-UART...
Communication with the module timed out, is the serial port configured correctly?
Im FHEM Log taucht dann immer wieder
2024.01.29 14:35:38.175 3: myHmUART device closed
2024.01.29 14:35:38.176 3: Setting myHmUART serial parameters to 115200,8,N,1
2024.01.29 14:35:38.176 1: /dev/ttyAMA10 reappeared (myHmUART)
2024.01.29 14:35:39.177 0: HMUARTLGW myHmUART send: 00 00
2024.01.29 14:35:42.177 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2024.01.29 14:35:45.178 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2024.01.29 14:35:48.180 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2024.01.29 14:35:51.182 1: HMUARTLGW myHmUART did not respond after all, reopening
list myHmUART
Internals:
CNT 1
Clients :CUL_HM:
DEF /dev/ttyAMA10
DevState 1
DevType UART
DeviceName /dev/ttyAMA10@115200
FD 4
FUUID 65b23488-f33f-2728-b75c-40d2df495894c995
LastOpen 1706534895.88929
NAME myHmUART
NOTIFYDEV global
NR 479
NTFY_ORDER 47-myHmUART
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
eventCount 230
model HM-MOD-UART
.attraggr:
.attrminint:
Helper:
AckPending:
1:
cmd 00
dst 0
frame FD00030001009E03
resend 2
time 1706534896.89067
LastSendLen:
3
Log:
IDs:
sys
all
MatchList:
1:CUL_HM ^A......................
PeerQueue:
HASH(0x5555c0af9ca0)
HASH(0x5555c0b8f558)
HASH(0x5555c0b88d20)
HASH(0x5555c0b8bfa0)
HASH(0x5555c0b99c28)
HASH(0x5555c0b74f30)
HASH(0x5555c0b889d8)
HASH(0x5555c0b80d50)
HASH(0x5555c0b89c00)
HASH(0x5555c0b80b28)
HASH(0x5555c0b8bec8)
HASH(0x5555c0b912c0)
HASH(0x5555c0b75db0)
HASH(0x5555c0b745e8)
HASH(0x5555c0b74cf0)
HASH(0x5555c0b80780)
HASH(0x5555c0b85a10)
HASH(0x5555c0b7f4c8)
HASH(0x5555c0b8ebf8)
HASH(0x5555c06ded28)
HASH(0x5555c06de740)
HASH(0x5555c071aad8)
HASH(0x5555c071ab20)
HASH(0x5555c06f1ce8)
HASH(0x5555c05c7008)
HASH(0x5555c06b0a68)
HASH(0x5555c0662360)
HASH(0x5555c05c6a38)
HASH(0x5555c0704348)
HASH(0x5555c06c2360)
HASH(0x5555c0c119b0)
HASH(0x5555c0c132c0)
HASH(0x5555c0b7c570)
HASH(0x5555c0b828d0)
HASH(0x5555c0b94090)
HASH(0x5555bcb05b58)
HASH(0x5555c0b7fd98)
HASH(0x5555bc0ddd58)
HASH(0x5555c058f348)
HASH(0x5555c0b82360)
HASH(0x5555c0484328)
HASH(0x5555c0b77188)
HASH(0x5555c0b81380)
HASH(0x5555c0b7c978)
HASH(0x5555c0b7b1c0)
HASH(0x5555c0583110)
HASH(0x5555c0b7ca08)
HASH(0x5555c0b853c8)
HASH(0x5555c0b74708)
HASH(0x5555c04b1e30)
HASH(0x5555c0b74930)
Peers:
1A4F15 pending
1F4C71 pending
224A6C pending
225B8C pending
25690E pending
256957 pending
2DAF1C pending
322B56 pending
33833F pending
338EFA pending
50A319 pending
55ADA8 pending
593148 pending
60C117 pending
67FC65 pending
744318 pending
READINGS:
2024-01-29 14:11:47 D-type HM-MOD-UART
2024-01-29 14:28:16 cond init
2024-01-29 14:11:47 loadLvl suspended
2024-01-29 14:28:15 state opened
helper:
Attributes:
group HomeMatic
hmId AA12BD
logIDs sys,all
room Transmitter
Readings
[code]
D-type HM-MOD-UART 2024-01-29 14:11:47
cond init 2024-01-29 14:39:06
loadLvl suspended 2024-01-29 14:11:47
state opened 2024-01-29 14:38:53
Verglichen mit meinem LAN Gatway fehlen mir Einträge wie :
D-HMIdAssigned, D-HMIdOriginal, D-LANfirmware, D-firmware, D-serialNr
Klar, die werden wohl für das Modul anders lauten, aber weder die Seriennummer noch die HMid des Gerätes selbst sind zu finden.
Und ich hab auch keine Möglichkeit gefunden, die Seriennummer z.b. einzugeben. Ob es notwendig ist, weiß ich allerdings auch nicht.
Über die vccu scheint das neue HM-MOD-UART bereits verbunden zu sein.
Internals:
.AttrList .devInfo .mId .stc IODev IOgrp actAutoTry:0_off,1_on actCycle actStatus aesCommReq:1,0 aesKey:5,4,3,2,1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto commStInCh:on,off do_not_notify:1,0 dummy:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading expert:multiple,defReg,allReg,rawReg,templ,none firmware hmKey hmKey2 hmKey3 hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger ignore:1,0 model modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 msgRepeat oldreadings param readOnly:0,1 readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiLog:1,0 serialNr showtime:1,0 stateFormat:textField-long subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic timestamp-on-change-reading
DEF AA12BD
FUUID 5efcc51f-f33f-58ba-6ad2-4e300ebcc044a4b0
IODev myHmUART
NAME vccu
NR 341
NTFY_ORDER 48-vccu
STATE CMDs_done_Errors:1
TYPE CUL_HM
channel_01 vccu_Btn1
disableNotifyFn 1
READINGS:
2024-01-29 14:11:47 .associatedWith vccu,vccu_Btn1,vccu
2024-01-29 14:11:47 IODev myHmUART
2024-01-29 13:28:04 cfgState updating
2024-01-29 13:28:39 commState CMDs_done_Errors:1
2024-01-29 13:28:39 state CMDs_done_Errors:1
helper:
HM_CMDNR 66
mId 0000
peerFriend -
peerOpt -:-
regLst 0
rxType 1
cmds:
TmplKey :no:1706533907.68307
TmplTs 1706533907.68307
cmdKey 0:1:1::vccu:0000:00:
cmdLst:
assignHmKey noArg
clear (readings|all)
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
raw -data- [...]
reset noArg
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
status noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
vccu
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
.mId no
autoReadReg 4_reqStatus
expert rawReg
model ACTIONDETECTOR
room Transmitter
subType virtual
webCmd virtual:update
Was hab ich falsch gemacht ?
Bzw. Was hab ich vergessen ?
Oder geht das einfach mit einem Raspberry Pi 5 nicht ?
Danke
Siehe hier https://forum.fhem.de/index.php?topic=136441.msg1299036#msg1299036
Danke, ich werde mir das mal in Ruhe anschauen.
wenn der hmuart läuft, musst du die vccu noch "reparieren", siehe wiki.