Hallo!
Nach dem Auftakt mit den Techem HKVs ist der nächste Schritt in Planung. Ich habe mich für Homematic entschieden und mich durch den Anhang
http://fhem.de/Heimautomatisierung-mit-fhem.pdf (http://fhem.de/Heimautomatisierung-mit-fhem.pdf)
gegraben und im Wiki geblättert
https://wiki.fhem.de/wiki/HomeMatic_Installieren (https://wiki.fhem.de/wiki/HomeMatic_Installieren)
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen (https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen)
Ich habe einen Raspi 2, einen nanoCUL 868MHz mit aktueller FW und zwei Schaltsteckdosen
Homematic 132989A0 Funk-Schaltaktor .
1. Brauche ich die Timestamp FW? Wird empfohlen, aber ist wohl nur in einem 57-Seiten Thread dokumentiert:
https://forum.fhem.de/index.php/topic,24436.840.html?PHPSESSID=0r3t88dgv7tnd3v8ehgjmgbei0 (https://forum.fhem.de/index.php/topic,24436.840.html?PHPSESSID=0r3t88dgv7tnd3v8ehgjmgbei0)
2. Wenn diese FW wirklich besser ist, wo finde ich eine knackige Anleitung zur Installation?
3. Ziel der ersten Fingerübung ist es, die Schaltsteckdose über ein kleines Webinterface schalten zu können. Sollte doch gehen, ohne physikalischen Sensor (Schalter), wie im Dummy-Beispiel, oder?
Tausend Dank vorab für kurze Infos!
Schön, nur leider hast du dabei übersehen, dass zwischenzeitlich dringlich empfohlen wird, ein _natives_ Interface zu verwenden, v.a. also den HM-MOD-RPi-PCB. Da gibt es einen Wiki-Artikel zu, wei man das ggf. auch an anderen Systemen wie einem Pi betreiben kann.
Die TS-CUL-Fw ist aus guten Gründen empfohlen, eine Anleitung ist - soweit ich mich entsinne - im ersten Beitrag des Mega-Threads enthalten.
Ich würde aber eher empfehlen, erst mal nichts an dem CUL zu machen, sondern eine VCCU einzurichten und asap ein "richtiges" Interface zu besorgen. Als 2.-IO kann der CUL tauglich sein (mußt du austesten, das ist Funk und damit für Überraschungen in (fast) alle Richtungen gut, vor allem in wenig erheiternde...)
Ansonsten ist CUL_HM mMn. nicht geeignet für "Trockenübungen": Das Modul geht von einer bidirektionalen Kommunikation aus, und wenn es die mangels Hardware nicht gibt, sieht man logischerweise v.a. Fehlermeldungen...
Besten Dank, kleiner Tipp, warum diesen Spezial-Raspi-GPIO-Sender? Reichweite? Ich will erstmal nur innerhalb eines Raumes schalten.
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)
Eine VCCU ANSTATT des FW-mods für den CUL?
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)
Ich werde mich an der FW am Wochenende mal versuchen. Da braucht's ja auch noch irgendwelche zusätzliche Software im Raspbian, wenn ich das richtig verstanden habe.
Trockenübungen ja nun nicht, ich hab die Hardware ja da, nur halt keinen Sensor/Schalter (wollte die Schaltsteckdosen wirklich nur per Web-GUI schalten, später dann mit Zeitprogramm.
Hallo Claudio,
vielleicht noch ein wichtiger Artikel:
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Leg von mir aus los mit dem CUL, geht auch mit der Standard Firmware, aber wundere Dich nicht wenn es Fehler gibt. Aber wenn was nicht geht und es dauerhaft der CUL sein soll ist die TS Firmware Pflicht!
Viel einfacher ist es mit HM-MOD-RPI-PCB
Reichweite? Wie sagt eq3 immer: 100 m im freien Feld ;)
ZitatEine VCCU ANSTATT des FW-mods für den CUL?
Da hast Du was falsch verstanden. Kurzum: Eine VCCU sollte man einrichten, es ist nicht verkehrt es zu tun.
Sie ersetzt aber für den CUL nichts!
Viel Erfolg
Otto
Kurz aus meiner Erfahrung...
MiniCUL V2 868 für homematic, es dauert 2 bis 3 sek bis der MK grün meldet. (Empfanhsbestätigung)
HM Gateway per wlan: halbe bis max 1 sek.
Also ja, klare Empfehlung zum "original"
Gesendet von meinem S60 mit Tapatalk
@Otto: Danke für die Klarstellung. Wo kann man das GPIO-Hütchen denn fertig kaufen? Sowas selbst löten kann ich glaube ich nicht...
@Frank_Huber: Ist "HM Gateway per WLAN" original HM HArdware? Gibtz einen Link? :-)
Kuck mal im Marktplatz. Ist das original gateway mit einem esp.
Gesendet von meinem S60 mit Tapatalk
Zitat von: claudio-fhem am 11 September 2019, 22:03:25
Wo kann man das GPIO-Hütchen denn fertig kaufen? Sowas selbst löten kann ich glaube ich nicht...
Irgendwo im Internet :) ebay oder so
Alternativ holst Du das LAN-Gateway ;)
Das hier:
https://www.ebay.de/itm/Homematic-Funkmodul-fur-Raspberry-Pi-Fertiggerat/123880921931?hash=item1cd7e0db4b:g:gtwAAOSws-1ct4HD (https://www.ebay.de/itm/Homematic-Funkmodul-fur-Raspberry-Pi-Fertiggerat/123880921931?hash=item1cd7e0db4b:g:gtwAAOSws-1ct4HD)
...ich will nicht noch mehr Fehlkäufe... ;-)
Sieht vom Bild her gut aus :)
Zitat von: claudio-fhem am 11 September 2019, 18:43:29
[...] ich hab die Hardware ja da, nur halt keinen Sensor/Schalter (wollte die Schaltsteckdosen wirklich nur per Web-GUI schalten, später dann mit Zeitprogramm.
Es sollte schon mit der vorhandenen Hardware kein Problem sein, die Schaltsteckdosen einzubinden, einfach pairen und sicherstellen, dass das abgeschlossen ist und nichts mehr "pending" (s.u.).
autocreate wird dir für jede HM-Hardware mindestens ein FHEM-Device anlegen, darüber kannst du das dann unmittelbar in FHEMWEB schalten bzw. auch mit FHEM-Befehlen, über at, WeekdayTimer, notify, DOIF, ....
Werden mehrere Devices angelegt (bei den Dosen eher nicht), ist das Device mit der 6-stelligen Nummer das "Hauptdevice", da ist dann auch zu sehen, ob alle Nachrichten an das Gerät durch sind (wenn nein, gibt's "CMD's pending"...).
Du solltest sowas erst mal ausprobieren, und nicht vorher fragen, ob die Anleitung noch aktuell ist (o.ä.); das verwirrt und du vergibst dir die Chance, dabei besser zu lernen, wie CUL_HM (bzw. FHEM) "tickt" ...
Nochmal zum mitmeiseln:
Ich habe bei Homematic bei der Funkanbindung meiner Aktoren (u.a.) folgende Optionen:
1. CUL 868 Standard-FW (wenig empfohlen)
2. CUL 868 Timestamp-FW (schon besser)
3. Raspi-Aufstecker (besser, aber...)
HM-MOD-RPi-PCB
4. Den LAN-Extender der Originalserie
https://www.elv.de/homematic-funk-lan-gateway.html
Bevor ich jetzt 27.- Euro in den Raspihut ausgebe und das HM-Gateway für 79.- Euro am Ende die einzige Option ist, mehr als einen Raum zu erreichen...
Aber weil ich den CUL jetzt schon hier habe, werde ich damit anfangen. Mit der TS-Firmware (hoffentlich... liest sich komplex).
Und dann eine VCCU definieren. Und dann die Homematic Steckdosen damit pairen. Und dann schalten können über die GUI.
Also der Raspi Funkaufsatz läuft bei mir quer durchs Haus, 3 Wände, ca. 10 m, ohne Probleme. Besser als das MAX! von eq3.
peterw
Stahlbetondecken (Ende der 60er gebaut, einiges an Angsteisen)? 2-3 Geschosse? :-)
Du kannst das Raspi-Modul an einen ESP "stecken" und in der ganzen Wohnung/Haus welche verteilen, überall wo eine Steckdose und WLAN ist...
Dann in fhem eine vccu und gut is...
Sofern du KEINE Homematic IP Komponenten verwenden willst/musst...
Also immer schauen, dass du bei Homematic "Classic" (bidCos) was passendes findest...
Sonst läuft Anbindung und Integration in fhem anders!
Stichworte: CCU2 bzw. CCU3 (nicht verwechseln mit vccu!) und HMCCU-Modul...
Gruß, Joachim
Danke für die Antwort! ESP? Whot? :-)
Du meinst ich soll ein paar von den HM Raspi-Hütchen über's Haus verteilen und per WLAN (keine gute Option, ich komme kaum durch eine Wand) oder LAN-over-Powernet (klappt mittelschlecht hier, Elektrik zu alt?) verbinden?
Ich habe schon dran gedacht über den Dachboden etwas CAT6 zu verteilen. Aber schön ist der Gedanke nicht...
Ich habe mir die Anleitung zur TS-Firmware mal durchgelesen (incl. der "von Hand in der config ändern" Teile), ich denke das ist nix für den Einstieg.
Also einen HM Raspihut oder doch die HM Funk-LAN Sendeeinheit. Die Steckdosen liegen hier (und noch etwas anderer HM Schnickschnak), aber irgendwie stecke ich noch in den Startlöchern fest.
Es gibt auch "Seriell-zu-LAN" Adapter...
Dann ist das Raspi-Hütchen (lustige Bezeichnung ;) ) quasi ein HM-LAN-Adapter nur deutlich günstiger...
Wenn du eh schon Empfangsprobleme erwartest ist ein CUL (zusätzlich zum "Gehampel" mit der T-FW) eh keine gute Wahl...
Also eigentlich auch ohne zu erwartende Funkprobleme schon nicht... ;)
Gruß, Joachim
Hast du schon einen PI!?
Dann würde ich einfach mal mit dem Raspi-Hütchen anfangen...
...günstigster Einstieg und wenn die Reichweite nicht reicht nix verloren oder falsch gemacht...
Und am besten gleich eine vccu anlegen...
...dann kannst du die Reichweite mit anderen "Hütchen" oder anderen HM-Funk-IOs erweitern (besserer Antenne am vorhandenen "Hütchen)...
EDIT: und wenn du von einem PI umsteigst kannst du einfach einen USB oder WLAN oder LAN-Adapter dran machen und weiterverwenden... :)
Viel Spaß, Joachim
EINEN Raspi? Die vermehren sich hier irgendwo bei mir im Regal...
Den nanoCUL V3.0 mit Standard FW habe ich hier liegen. Ich glaube, damit fange ich mal an und bestelle mit den Hut zum Raspi oder die HM LAN-Funk-Station.
Bekommt diese HM-LAN-Funk-Station irgendwie auch mal updates? Oder betreibt man die ein Leben lang mit der FW, die bei Lieferung mitkommt? Sowas vermeide ich eigentlich gerne...
Man kann die fw auch updaten, ist jetzt aber seit ca. 3 Jahren fast dieselbe...
Aber was grundsätzliches: Vielleicht ist HM-BidCoS nicht die richtige Technologie für dein Umfeld. Schon mal über Alternativen nachgedacht, bevor du jetzt groß investierst? (HM-BidCoS wird von eQ-3 zwar noch verkauft, aber neues gibt es schon seit einiger Zeit nur noch in HM-IP...).
Würde mal die Stichworte Z-Wave oder EnOcean in den Raum werfen. Mind. ZWave "macht" mesh, was evtl. bei deinen Funkbedingungen eine gute Idee sein könnte... Und beides geht mit einem USB-Dongle, für ZWave kostet das ca. 25 Euro, und jeder strombetriebene Aktor dient potentiell als "Repeater" ;) . ZWave ist (mMn.) leider etwas schwieriger zu durchschauen als CUL_HM, geht aber notfalls & experimentell auch mit CUL.
(ZigBee macht auch mesh, ist aber reichweitenmäßig ähnlich wie WLAN; wenn du da also Schwierigkeiten hast, ist das evtl. nicht zu empfehlen; sonst wäre das (@deCONZ) ähnlich einfach wie CUL_HM ;) ).
Just my2ct...
OK, dann mal die Karten auf den Tisch: Als Einstieg wollte ich in EINEM Raum folgendes:
- Ein paar Funksteckdosen schalten (über GUI)
- Ein HM Raumthermometer und das HM Heizkörperthermostat (beides liegt schon hier) peeren, damit die Heizung auf die Raumtemperatur besser reagiert (das jetzige Thermostat ist kein burner und ich wollte auch mal von "außen" (unterwegs) korrigieren können, falls nötig).
Das soll das erste, kleine Projekt mit HM werden. Kann das auch ein Raspi zero hinbekommen (mit HM-Raspihut als Funkeinheit)? Ich habe hier einen zero mit aufgelöteten GPIO Pins. Ansonsten werde ich einen Raspi 2 nehmen, der sollte das allemal schaffen, oder?
Wenn du die HW dann schon mal hast und sich alles inkl. fhem-PI im selben Raum befinden...
...und du schon mal anfangen willst (anders lernt man ja nix bzw. halt nur theoretisch):
Nimm den CUL und einen PI und leg los...
Das sollte sogar ohne Timing-FW noch gehen...
...einzig die Fensterkontakte sind etwas "zickig"...
Wenn doch nicht: umstellen...
Und wenn auch das nicht hilft: Hütchen ;)
Anmerkungen:
Beim Anlernen: geduldig sein! Immer ein Gerät nach dem anderen VOLLSTÄNDIG anlernen (Pairen)!!
Warten bis bei der Kommunikation keine Fehler kamen überall irgendwelche set_ vor "Befehlen/Readings" weg sind und keine cmds_pending sind!
Erst dann mit dem nächsten Gerät weiter...
Wie ein vollständiges Pairing erkannt wird etc. sollte in den Homematic Wikis stehen...
Und: ab und an mal das "Anlernknöpfchen" drücken
Und: Geduld! Nicht wild reseten, löschen und neu anfangen!
Für die zunächst geplante Umgebung könnte vetm. ein PIZero auch tun, würde aber nicht damit anfangen...
Der kann/könnte aber später genau wie ein ESP mit "Hütchen" als Reichweitenvergrößerer dienen (ser2net)...
Aber wie Beta-User geschrieben hat: durchaus umsehen!!
Ich hatte damals auch mit ähnlichen Komponenten von MAX! angefangen, bin dann (Gott sei Dank) recht schnell auf Homematic "Classic"/bidCos (gab noch kein IP oder kam grad ganz neu mit wenig)...
Wenn ich heute anfangen würde, würde ich verm. auch ZWave, Zigbee, EnOcean näher betrachten...
...bzw. tue ich das eh schon und gehe bei neuen Geräten auch andere Wege als Homematic/Homematic IP...
Aber man muss ja mal anfangen...
...und nachdem du ja praktisch alles hast um zu beginnen: hau drauf! ;)
Viel Spaß, Joachim
OK, also:
1. Den nanoCUL mit StandardFW in fhem definieren
2. Die VCCU in fhem definieren und den nanoCUL als Sender zuweisen
3. Versuchen, ein HM-Gerät (für den Anfang eine Steckdose) zu pairen...
Ich versuch's. :-D
Bei der Steckdose gilt ähnliches wie beim Fensterkontakt ;)
Der Fensterkontakt ist "etwas eigen" (verm. wegen AES, ist aktiviert erst mal -> rjindeal [oder wie das genau heißt] installieren nicht vergessen!)...
...der Steckdosenschalter hat halt viele Kanäle -> es müssen viele Daten beim Anlegen/Anlernen/Pairen übertragen werden...
Da kann es dann schon mal sein, dass TimeOutRegisterRead etc. kommt.
Keine Panik: einfach warten. Noch mal getConfig anstoßen (evtl. vorher "Message-Queue" löschen geht am "Device" -> clear messageIrgendwas)...
Eine gute Idee ist auch HMINFO zu "definieren", damit lässt sich die Konfiguration bzgl. Homematic gut prüfen etc.
(Wenn das mit der Steckdose schon hakt evtl. gleich auf T-FW...)
ABER: fang ruhig genau so mal an! Auch die gewählte Reihenfolge ist gut! (CUL, vccu, (hminfo,) Steckdosenschalter anlernen)
Es ist ein gutes Gefühl, wenn man das erste Mal auf der Weboberfläche auf "die Glühbirne" klickt und die Dose schaltet :)
EDIT: noch mal der Hinweis: Ruhe bewahren! Nicht anfangen mit wildem Reset, Löschen etc.! Das ist eher (schwer) Kontraproduktiv! ;)
Gruß, Joachim
Ich bin noch nicht zum Testen gekommen, aber eine Frage:
Ich habe einen Raum, da komme ich mit Funk NIE hin, es wäre aber dringend nötig, das Heizkörperventil mit dem Magnetschalter (nicht der für Kunststofffenster, der im Rahmen sitzt) zu verbinden (Logik: Fenster auf - Heizung aus).
Ist so etwas sicher und wartungsarm mit den beiden HM Komponenten (direkt gepeert) darstellbar, also keine Frickelei, die in 10% der Fälle nicht funktioniert, weil die Heizung nicht aus/an geht?
Wäre sehr dankbar für ein paar Erfahrungswerte:-)
Wenn Fensterkontakt und Heizkörperthermostat sich funktechnisch gegenseitig erreichen können ist das kein Problem.
Wichtig: beides entweder Homematic bidCos ("Classic") oder beides Homematic IP...
Mischen geht (bei sowas) nicht!
Wenn dann würde ich die gleich direkt peeren/verbinden laut Anleitung OHNE Zentrale (und dann evtl. in fhem integrieren)...
Wenn das funktechnisch schlecht erreichbar ist kann es halt sein, dass du den Status in fhem (falls überhaupt integriert) nicht (sauber) mitkriegst bzw. halt auch mal "Fehlermeldungen" in fhem hast (ist aber nicht wirklich schlimm)...
Aber probier das doch, vielleicht reicht der Funk ja doch hin...
Ansonsten kannst du mit einem weiteren HMOD-PCB an einem ESP oder auch LAN-Adapter die Reichweite erhöhen...
Wichtig: das geht halt nur bei Homematic bidCos/"Classic"
Bei Homematic IP bräuchtest du eine weitere CCU und die dann zusätzlich per HMCCU-Modul in fhem (sollten soweit mir bekannt auch mehr als 1 CCU gehen)...
Gruß, Joachim
(Da schon fertig, in Teilen eben doppelt...)
Das direkte peeren würde schon gehen, aber Bitte welchen Sinn hat ein "vernetztes" Heizkörperventil, wenn du keine Netzwerkverbindung zur Zentrale hinbekommst????
Also entweder (LAN) Kabel legen und ein IO für den Raum verwenden (im Wiki zum Pi-Modul sind Möglichkeiten dargestellt, wie das geht), oder mal testen, ob nicht doch - via mesh ;) - ein anderes Funksystem für deine Bude besser geeignet wäre... :P
Ich bezweifle mittlerweile ernsthaft, ob ich mit Funk viel erreiche in dem Bunker. Um mit Wifi auch nur einigmaßen durch eine (1) Wand zu kommen, brauche ich USB-sticks mit 15-20 cm Antenne, selbst bei ansonsten freier Achse und nur 4-5 m Abstand zwischen den Geräten (eine gemauerte Wand dazwischen).
Was das Heizkörperventil mit Fensterschalter bringt, OHNE Zentrale? Na, hoffentlich ordentlich Heizkostenersparnis! Ich muss nicht auf irgendeinem Monitor sehen können (bei dieser Anwendung), wie der Status der beiden HM-Geräte ist, Hauptsache die Sache läuft. Keep it simple... ;-) Bei anderen HM-Anwendungen will ich natürlich schon fhem als Zentrale haben.
PS: Aber ich habe das richtig verstanden: Ich peere Thermostat und Schalter und dann wissen die beiden: Wenn der Schalter sagt "Ich bin offen", dann sagt das Ventil "Gut, dann mach ich dicht" und umgekehrt korrekt?
Ja, einfach peeren.
Und dann (mMn) beide Geräte wieder aus der Zentrale ablernen. Sonst sind nämlich die Batterien vermutlich recht schnell leer...
Und: Funk ist nicht gleich Funk! Die Reichweite kann eine deutlich andere sein, dabei gilt tendenziell: niedriger ist besser. Also kann 868MHz uU. durchaus durchkommen, wo WLAN schon lange schlapp gemacht hat.
Wenn du sie (erst mal) nicht in fhem/Zentrale haben willst/brauchst, dann kannst du sie auch einfach wie in den Bedienungsanleitungen steht "verbinden" (hatte ich ja bereits geschrieben)...
"Anlernen/Verbinden" ohne Zentrale...
Wird mit dem Heizkörperthermostat, wenn Funk echt so schlecht ist eh nicht anders gehen.
Zum Anlernen muss er montiert sein (zumindest mal gewesen) also ist er dort wo du keinen/kaum Funk zu haben glaubst...
Da wird anlernen und nachher Peeren über Zentrale (weil NACH dem Anlernen an eine Zentrale geht es nur noch über Befehle von der Zentrale) schwierig...
Wenn du sie dann (versuchsweise) doch in fhem aufnehmen willst, kein Problem.
Auch die bereits hergestellte Verbindung bleibt.
Wird auch in fhem angezeigt (liest ja die Register aus, da steht das dann bei den Geräten ja drin)...
Gruß, Joachim
Hihi, 20 min investiert. Rijnedael war bereits installiert.
Den nanoCUL angelegt (HM mode etc.). Eine VCCU angelegt (hmID vergeben). Die Schaltsteckdose in die Steckdose gesteckt. Gepairt. Hm, schalten geht nicht "ack miss" oder so...
Nochmal gepairt. Funzt! Lässt sich aus der GUI schalten.
Was mir nicht so gefällt: Es steht im Wiki für die Schaltsteckdose, dass es nach ein paar Wochen vorkommt, dass sie nicht mehr zuverlässig schaltet. Dann soll man den "Schaltaktor resetten und neu pairen". Das geht ja wohl nicht von remote locations... :-(
"Schaltaktor reset" = aus der Steckdose ziehen und 30 sec warten?
Hallo Claudio,
hast Du mal nen Link? Ich habe zwei Sorten Schaltsteckdosen, ich kann mich nicht erinnern damit schon mal Probleme gehabt zu haben.
Gruß Otto
Hallo Otto!
https://wiki.fhem.de/wiki/HM-LC-Sw1-Pl2_Funk-Zwischenstecker-Schaltaktor_1fach
...unten "Bekannte Probleme"
Mittlerweile habe ich auch den Raumtemp/Feuchtesensor angelernt und das Heizkörperthermostat.
Mir fehlt im Moment etwas die Idee, wie ich jetzt in fhem das "programm" mit den Solltemperaturen (des Raumthermometers) für das Heizkörperthermostat stricke und die beiden miteinander in fhem verkuppel...
Hallo Claudio,
und den hast Du wirklich?
mach mal bitte ein List von deinem Aktor.
Ich habe diese hier https://wiki.fhem.de/wiki/HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung
Und die Aufgabenstellung musst Du erläutern:
ZitatMir fehlt im Moment etwas die Idee, wie ich jetzt in fhem das "programm" mit den Solltemperaturen (des Raumthermometers) für das Heizkörperthermostat stricke und die beiden miteinander in fhem verkuppel...
Du redest von Solltemperaturen? Du willst dem Thermostaten ein Wochenprogramm verpassen? Du willst die Solltemperatur situationsabhänging anpassen? Spielt der Temperatursensor da eine Rolle? Gib mal am Besten auch ein list von den Beiden.
Gruß Otto
Hallo Otto!
Ja, ich habe den korrekten Schalter im Wiki verlinkt (habe noch einen zweiten davon mittlerweile angelernt):
Internals:
CFGFN
DEF 6C9924
FUUID 5d8798bd-f33f-d504-7611-9f60c1a87c99e7fb
IODev culOFF
LASTInputDev culOFF
MSGCNT 23
NAME HM_6C9924
NOTIFYDEV global
NR 134
NTFY_ORDER 50-HM_6C9924
STATE off
TYPE CUL_HM
chanNo 01
culOFF_MSGCNT 23
culOFF_RAWMSG A0E34A4106C99241357900601000024::-35.5:culOFF
culOFF_RSSI -35.5
culOFF_TIME 2019-09-22 18:14:32
lastMsg No:34 - t:10 s:6C9924 d:135790 0601000024
protCmdDel 16
protLastRcv 2019-09-22 18:14:32
protRcv 24 last_at:2019-09-22 18:14:32
protResnd 9 last_at:2019-09-22 17:55:20
protResndFail 3 last_at:2019-09-22 17:55:25
protSnd 18 last_at:2019-09-22 18:14:32
protState CMDs_done
rssi_at_culOFF cnt:24 min:-57 max:-35.5 avg:-44.52 lst:-35.5
rssi_culOFF cnt:5 min:-44 max:-36 avg:-39.6 lst:-36
READINGS:
2019-09-22 17:56:46 CommandAccepted yes
2019-09-22 17:56:14 D-firmware 2.6
2019-09-22 17:56:14 D-serialNr QEQ0012477
2019-09-22 17:56:18 PairedTo 0xZZZZZZ
2019-09-22 17:56:18 R-pairCentral 0xZZZZZZ
2019-09-22 17:56:19 R-sign off
2019-09-22 17:56:18 RegL_00. 00:00 02:01 0A:13 0B:57 0C:90 15:FF 18:00
2019-09-22 17:56:19 RegL_01. 00:00 08:00 30:06 56:00 57:24 93:5F 94:B3
2019-09-22 18:14:32 deviceMsg off (to VCCU)
2019-09-22 18:14:32 level 0
2019-09-22 18:14:32 pct 0
2019-09-22 17:54:45 powerOn 2019-09-22 17:54:45
2019-09-22 18:14:32 recentStateType info
2019-09-22 18:14:32 state off
2019-09-22 18:14:32 timedOn off
helper:
HM_CMDNR 52
PONtest 0
cSnd 111357906C99240201000000,011357906C9924010E
dlvlCmd ++A0111357906C99240201000000
mId 0002
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6C9924,00,00,00
nextSend 1569168872.76635
prefIO
rxt 0
vccu
p:
6C9924
00
00
00
mRssi:
mNo 34
io:
culOFF:
-27.5
-27.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO culOFF
flg A
ts 1569168872.66766
ack:
HASH(0x2b8e9f8)
3480021357906C992400
rssi:
at_culOFF:
avg -44.5208333333333
cnt 24
lst -35.5
max -35.5
min -57
culOFF:
avg -39.6
cnt 5
lst -36
max -36
min -44
shadowReg:
tmpl:
Attributes:
IODev culOFF
IOgrp VCCU:culOFF
alias Lampe
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.6
model HM-LC-SW1-PL-DN-R1
peerIDs 00000000,
room CUL_HM
serialNr QEQ00xxxxx
subType switch
webCmd statusRequest:toggle:on:off
Hier die Info zum Heizkörperthermostat:
Internals:
CFGFN
DEF 64AA00
FUUID 5d8793b5-f33f-d504-c072-1cbca04f4cf440d5
IODev culOFF
LASTInputDev culOFF
MSGCNT 13
NAME HM_64AA00
NOTIFYDEV global
NR 110
NTFY_ORDER 50-HM_64AA00
STATE Info_Cleared
TYPE CUL_HM
channel_01 HM_64AA00_Weather
channel_02 HM_64AA00_Climate
channel_03 HM_64AA00_WindowRec
channel_04 HM_64AA00_Clima
channel_05 HM_64AA00_ClimaTeam
channel_06 HM_64AA00_remote
culOFF_MSGCNT 13
culOFF_RAWMSG A0F16861064AA000000000AA8F8120000::-32:culOFF
culOFF_RSSI -32
culOFF_TIME 2019-09-22 18:19:17
lastMsg No:16 - t:10 s:64AA00 d:000000 0AA8F8120000
protLastRcv 2019-09-22 18:19:17
protRcv 5 last_at:2019-09-22 18:19:17
protState Info_Cleared
rssi_at_culOFF cnt:14 min:-40 max:-31.5 avg:-34.28 lst:-32
READINGS:
2019-09-22 18:06:04 Activity alive
2019-09-22 18:06:04 CommandAccepted yes
2019-09-22 18:06:04 D-firmware 1.4
2019-09-22 18:06:04 D-serialNr OEQ2091141
2019-09-22 18:06:04 R-pairCentral set_0xZZZZZZ
2019-09-22 18:19:17 actuator 0
2019-09-22 18:19:17 battery ok
2019-09-22 18:19:17 batteryLevel 3.3
2019-09-22 18:19:17 desired-temp 21.0
2019-09-22 18:19:17 measured-temp 24.8
2019-09-22 18:19:17 motorErr ok
2019-09-22 18:06:58 state Info_Cleared
2019-09-22 18:06:35 time-request -
helper:
HM_CMDNR 22
PONtest 1
cSnd 0113579064AA00000802010A130B570C90,0113579064AA000006
mId 0095
peerFriend
peerOpt -:thermostat
regLst 0
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +64AA00,00,00,00
nextSend 1569169157.59037
prefIO
rxt 2
vccu
p:
64AA00
00
00
00
mRssi:
mNo 16
io:
culOFF:
-24
-24
prt:
awake 0
bErr 0
brstWu 0
sProc 0
sleeping 1
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_culOFF:
avg -34.2857142857143
cnt 14
lst -32
max -31.5
min -40
shRegW:
07 04
shadowReg:
RegL_00. 02:01 0A:13 0B:57 0C:90
tmpl:
Attributes:
IODev culOFF
IOgrp VCCU:culOFF
actCycle 000:10
actStatus alive
alias Thermostat off
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr OEQ20xxxxx
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
...und zum Temp/Hum-Sensor:
Internals:
CFGFN
DEF 621C37
FUUID 5d878fdb-f33f-d504-39c2-e97c862baee98971
IODev culOFF
LASTInputDev culOFF
MSGCNT 26
NAME HM_621C37
NOTIFYDEV global
NR 89
NTFY_ORDER 50-HM_621C37
STATE T: 24.9 H: 40
TYPE CUL_HM
chanNo 01
culOFF_MSGCNT 26
culOFF_RAWMSG A0C188670621C3700000000F928::-60:culOFF
culOFF_RSSI -60
culOFF_TIME 2019-09-22 18:17:38
lastMsg No:18 - t:70 s:621C37 d:000000 00F928
protCmdPend 3 CMDs_pending
protLastRcv 2019-09-22 18:17:38
protRcv 27 last_at:2019-09-22 18:17:38
protState CMDs_pending
rssi_at_culOFF cnt:27 min:-60 max:-23 avg:-41.94 lst:-60
READINGS:
2019-09-22 17:14:35 Activity alive
2019-09-22 17:14:35 D-firmware 1.3
2019-09-22 17:14:35 D-serialNr OEQ1304922
2019-09-22 17:14:35 R-pairCentral set_0xZZZZZZ
2019-09-22 18:17:38 battery ok
2019-09-22 18:17:38 humidity 40
2019-09-22 18:17:38 state T: 24.9 H: 40
2019-09-22 18:17:38 temperature 24.9
cmdStack:
++A001135790621C3700050000000000
++A001135790621C37000802010A130B570C90
++A001135790621C370006
helper:
HM_CMDNR 24
PONtest 1
mId 00BC
peerFriend
peerOpt p:THSensor
regLst 0
rxType 132
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +621C37,00,00,00
nextSend 1569169058.1622
prefIO
rxt 0
vccu
p:
621C37
00
00
00
mRssi:
mNo 18
io:
culOFF:
-56
-56
prt:
bErr 0
sProc 2
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_culOFF:
avg -41.9444444444444
cnt 27
lst -60
max -23
min -60
shadowReg:
RegL_00. 02:01 0A:13 0B:57 0C:90
tmpl:
Attributes:
IODev culOFF
IOgrp VCCU:culOFF
actCycle 000:10
actStatus alive
alias Temp off
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
model HM-WDS40-TH-I-2
room CUL_HM
serialNr OEQ130xxxx
subType THSensor
PS: Zwischenzeitlich hatte sich das Heizkörperthermostat verabschiedet:
2019-09-22_17:31:01 HM_64AA00 Activity: alive
2019-09-22_17:31:01 HM_64AA00 D-firmware: 1.4
2019-09-22_17:31:01 HM_64AA00 D-serialNr: OEQxxxxxx
2019-09-22_17:36:39 HM_64AA00 Info_Cleared
2019-09-22_17:36:41 HM_64AA00 Info_Cleared
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:36:43 HM_64AA00 CMDs_pending
2019-09-22_17:51:01 HM_64AA00 Activity: dead
...ist aber nach einem weiteren anlernen wieder aufgetaucht:
2019-09-22_18:06:04 HM_64AA00 Activity: alive
2019-09-22_18:06:04 HM_64AA00 D-firmware: 1.4
2019-09-22_18:06:04 HM_64AA00 D-serialNr: OEQ2xxxxxx
2019-09-22_18:06:04 HM_64AA00 R-pairCentral: set_0xZZZZZZ
2019-09-22_18:06:04 HM_64AA00 CMDs_pending
2019-09-22_18:06:04 HM_64AA00 CMDs_done
2019-09-22_18:06:35 HM_64AA00 CMDs_done
2019-09-22_18:06:35 HM_64AA00 time-request: -
2019-09-22_18:06:37 HM_64AA00 actuator: 0
2019-09-22_18:06:37 HM_64AA00 battery: ok
2019-09-22_18:06:37 HM_64AA00 batteryLevel: 3.2
2019-09-22_18:06:37 HM_64AA00 desired-temp: 21.0
2019-09-22_18:06:37 HM_64AA00 measured-temp: 25.3
2019-09-22_18:06:37 HM_64AA00 motorErr: ok
2019-09-22_18:06:37 HM_64AA00 CMDs_pending
2019-09-22_18:06:40 HM_64AA00 CMDs_pending
2019-09-22_18:06:57 HM_64AA00 Info_Cleared
2019-09-22_18:06:58 HM_64AA00 Info_Cleared
Es sind Luftlinie nur 1.5 m zwischen dem nanCUL und dem Heizkörperthermostat, aber einiges an Elektronik liegt dazwischen.
Was ich gerne erreichen möchte:
Heizkörper Solltemp 21°C von 07:00 bis 22:00 aber gemessen vom Temp/Hum-Sensor, nicht am Thermostat selbst.
(für die übrige Zeit 17°C als Soll am Temp/Hum-Sensor)
:-)
Naja nicht ganz, Du hast den HM-LC-SW1-PL-DN-R1 - ok ist das Modell ohne Strommessung. Ich würde auf den Satz im Wiki nicht viel geben, es geht um den Vorläufer, andere Firmware, der Artikel ist von 2013.
Dein Thermostat hat sich nicht verabschiedet, der ist nicht fertig gepaired:
set_0xZZZZZZ
Da darf nicht set_ stehen sondern nur deine HMId. Die durch ZZZZZZ zu ersetzen kannst Du lassen, das irritiert nur die, die Dir helfen wollen.
Definiere Dir hminfo und mach dort configcheck, das hilft Probleme zu erkennen.
Als Sollwertgeber für den Thermostaten hast Du Dir aus meiner Sicht ein ungünstiges Modell ausgesucht, hättest Du besser den Raumthermostaten nehmen können.
Ob die beiden was direkt miteinander anfangen können weiß ich nicht genau, da muss jemand anderes was dazu sagen.
Aber es scheint zu gehen: https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_01_Weather
Ich würde es immer direkt peeren und nicht über FHEM steuern.
Aber erst beide Geräte richtig fertig pairen !!!
Gruß Otto
Dann müsste ich im Thermostat selbst das Programm erstellen/ändern? Wie ging noch gleich ein peering in fhem? :-)
Kann ich mit WeekdayTimer die Schaltsteckdose für jeden Wochentag zu bestimmten (unterschiedlichen) Zeiten (am besten mit einer kleinen Portion Zufall bei der Schaltzeit, z.B. +/- 30 min) für 2-3 h einschalten? Gibt man in das "define" dann alle Tage/Schaltzeiten ein? Oder kann man die aus einem Textfile einlesen lassen?
Zitat von: claudio-fhem am 22 September 2019, 19:05:49
Wie ging noch gleich ein peering in fhem? :-)
Willst Du mich veräppeln? Steht doch oben in meinem Link?
Zum Rest kann ich nix sagen...
Ein config_check ergibt:
configCheck done:
missing register list
HM_621C37: RegL_00.
Register changes pending
HM_621C37
peer list incomplete. Use getConfig to read it.
incomplete: HM_621C37:
templist mismatch
HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Das Heizkörperthermostat habe ich nochmals gepairt, das hat dann funktioniert (set_ ist weg). Der HM_621C37 ist der Temp/Hum-Sensor. Laut Log-file werden von dem aber alle 3 min Temp/Hum.-Daten empfangen. Ich habe das "getConfig" für das Gerät in der GUI gemacht, aber es hat sich im config_check nichts verändert. Nochmal pairen hat auch nichts gebracht.
Ich habe das Weekprofile Modul gefunden, damit kann man wohl die Temperaturprogramme der Heizungsventile editieren. Ich habe nur noch nicht verstanden WIE....
Use getConfig to read it.
Der Temperatursensor hat noch nicht alle Werte in FHEM, also musst Du das machen was da steht ;)
Und bevor Du irgendwelche Module bemühst mach es doch erstmal so:
https://wiki.fhem.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten
Zitat von: claudio-fhem am 22 September 2019, 19:45:38
...Ich habe das "getConfig" für das Gerät in der GUI gemacht, aber es hat sich im config_check nichts verändert. Nochmal pairen hat auch nichts gebracht.
...
Naja, dann kann der CUL dran Schuld sein. Je mehr Daten übertragen werden um so schwieriger wird es. Manche Geräte sind sensibler als andere.
Du kannst es immer wieder probieren. Ruhe bewahren. Nichts rücksetzen und löschen.
Vor einem neuen getConfig kannst Du ein clear msgEvents machen.
OK, ich bleibe dran! Bis der Temp/Hum-Sensor nicht sauber funktioniert werde ich ihn nicht mit dem Thermostat peeren.
Das richtige Temp.programm für den Thermostat ist wichtiger, damit ich nicht morgen kalt sitze... :-)
Montag und Dienstag habe ich schon "reingeschoben" (dauert, ich warte immer nach jedem Tag, bis keine Messages mehr in der Warteschlange hängen...
Kann ich nach dem "Sonntag" (dem letzten Tag) irgendwie im Thermostat nachschauen, ob das richtige Programm angekommen ist? :-)
PS: Hab's gefunden, sieht gut aus im Thermostat, nichts "pending" und alles wie gewünscht mit den Schaltpunkten...
Na eigentlich war in meinem Link auch die Massenänderung und die Verwaltung mit Templates Sicherung und Wiederherstellung beschrieben.
Die Zeiten stehen doch nach der Änderung in den Readings im _Climate Channel?
Ist alles etwas überwältigend für die ersten paar Stunden... :-)
configCheck done:
missing register list
HM_621C37: RegL_00.
HM_64AA00: RegL_00.
HM_64AA00_Clima: RegL_01.,RegL_07.
HM_64AA00_ClimaTeam: RegL_01.
HM_64AA00_Climate: RegL_01.
HM_64AA00_Weather: RegL_01.
HM_64AA00_WindowRec: RegL_01.
HM_64AA00_remote: RegL_01.
Register changes pending
HM_621C37
templist mismatch
HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Irgendwie war die Programmierung im Thermostat wieder weg, also nochmal eingespielt, jetzt stimmt's und ich habe hier:
configCheck done:
missing register list
HM_621C37: RegL_00.
templist mismatch
HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
Hello again!
Ich habe alles über Nacht laufen lassen, aber immer noch dies hier:
configCheck done:
missing register list
HM_621C37: RegL_00.
templist mismatch
HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
HM_621C37 ist der Temp/Hum.-Sensor. Ich haben ihn noch mehrfach gestern gepairt mit der VCCU, ohne Veränderung. Bringt's was, wenn ich dem nochmal die Batterien raus mache und danach neu paire? Oder ist das nur mit der Timestamp-Firmware zu beheben? :-)
Das sind zwei Themen. Das erste sollte über ein einfaches getConfig zu lösen sein (clear all vorher machen, vermutlich ist da manches noch pending...).
Das zweite ist was ganz anderes, und der Fehler steht auch dort: Die File existiert nicht => erstellen, wie am von Otto angegebenen Ort erläutert (bzw. darauf achten, dass das richtige Verzeichnis hinterlegt ist und die richtigen Rechte gesetzt sind)...
Guten Morgen Claudio,
hektische Aktionen wie reset batterie raus oder was auch immer hilft nicht und ist meist kontraproduktiv. Du hast zu 90% Probleme mit dem IO (nur meine Mutmaßung) TS Software kann helfen, besser ist ein ordentlicher Homematic IO.
Der Zweite Fehler ist erstmal nur Kosmetik. Das Problem kannst Du mit einem save erledigen:
https://wiki.fhem.de/wiki/HomeMatic_HMInfo_TempList/Weekplan
Gruß Otto
Hi Beta!
Ja, die zweite Meldung irritiert mich auch nicht wirklich, das ist wohl die default temperature Datei für den Heizkörperthermostat (in welchem Verzeichnis ist noch mal fhem installiert? Habe gestern abend 20 min versucht es herauszufinden und bin gescheitert... War spät).
Den Sensor habe ich ja schon diverse Male mit clear und getConfig misshandelt, aber ohne Erfolg... es bleiben CMDs pending...
Hi Otto!
OK, ich versuch's nochmal über den Tag mit pairen. Was ist aus deiner Sicht "ein ordentlicherHomematic IO" für eine zunächst begrenzte Anlage? Das Raspi-Hütchen?
Wie Otto schrieb: Kein Hektik, das ist hochgradig kontraproduktiv. Einmal clearMsg (?), dann _1x_ getConfig und dann WARTEN. Das einzige, was ggf. hilft, ist, den Knopf am Thermostat zu drücken.... Aber sonst: Hände weg!
Was die Datei angeht: Auch die mal in Ruhe suchen, das bildet... (Tipp: "man locate"), du hast ja Zeit, während du wartest ;D .
Zitat von: claudio-fhem am 23 September 2019, 09:21:39
(in welchem Verzeichnis ist noch mal fhem installiert? Habe gestern abend 20 min versucht es herauszufinden und bin gescheitert... War spät).
Für die FHEM Kommandozeile:
{qx(pwd)}Es gibt nur zwei eq3 IOs für Homematic classic neu zu kaufen. Wenn man basteln will https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Oder wenn man nicht basteln kann/will: https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
...was ich nicht verstehe: Die Temp/Hum. Daten von dem Sensor kommen fleissig rein, aber das pairen bleibt immer stecken, wenn man die pendings cleared und danach getConfig aufruft (set), bleibt beides hängen und kommt nicht durch.
Ich werde wohl noch mal einen Abend Zeit in diese Timestamp Firmware investieren.
Was genau ist an dem Bausatz für HM-LGW-O-TW-W-EU denn zu bauen? Die beiden Platinen über Pins zusammenlöten? Wofür ist dieser Metallringe, den man bei dem Bausatz/fertige Platine auf eBay immer wieder mal neben der Platine sieht?
Dass Daten reinkommen, ist normal (gibt es hier x-fach unter "Kenne das Gerät xy nicht, wo kommt das her...?").
Wenn im Reading zur Zentrale kein "set_.*" mehr drin steht, sondern die HmID der Zentrale (VCCU), ist der Teil abgeschlossen. Dann bitte in Ruhe lassen mit neu Pairen. Dann _nur noch_ getConfig verwenden (as described: 1x "sauber" anschubsen, ggf. aber mehrfach Knöpfchen drücken, bis einfach die Zeit runter läuft...).
Das LGW ist doch ein Komplettgerät, oder? (Kann sein, dass es auch einen Bausatz gibt). Zum HM-MOD-RPi-PCB gibt es einen "Metallring" (einen Magneten...). Der ist für die Stromversorgung des Pi. Steht in der Anleitung, wie es geht (die kann man auch vorab downloaden...).
Die Temp/Hum. Daten sind schon von dem Sensor der nicht richtig paired, ich kann den ja manipulieren (warm/kalt) und sehe, wie sich die Werte ändern.
Also hier ist das Hütchen ein Bausatz:
https://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html
...und dann habe ich da noch das hier gefunden:
https://www.elv.de/homematic-funk-modulplatine-fuer-raspberry-pi-3-rpi-rf-mod-komplettbausatz.html
Aber wenn ich zu den 39.95 plus Versand noch einen Raspi 3 mit Gehäuse und Netzteil dazurechne ist das doch mindestens genauso teuer wir das HM LAN-Funkmodul mit ca. 70-80.- Euro?!?
1. Du willst nicht unbedingt eine CCU bauen (die könnte man virtualisieren (steht im Wiki...)) = man braucht keinen 2. Pi... (man braucht nicht mal einen PI, man kann das auch "woanders" betreiben...)
Lies bitte den Artikel zu dem Pi-Bausatz im Wiki, da steht doch das meiste drin dazu, denke ich...
2. ist mWn. der 2. Bausatz nicht für BidCoS geeignet, nur für HM-IP
Was den WHT angeht: ich hatte den ursprünglich auch mal an einem CUL@Standardfirmware angelernt.
Auch beim Pairen gilt: _1x_ "from the scratch" anstoßen, und dann aber warten, bis das vollständig durch ist (=GEDULD)! Ggf. Knopf drücken, aber nicht mehr...
Claudio, Du musst ruhiger werden - Du haust alles durcheinander.
Meine beiden Links zum Wiki beschreiben nicht dasselbe, das Langateway ist fertig, das RPI Modul ist zum Löten. Der Metallring ist eigentlich keiner sondern aus Ferrit. Er dient der Entstörung.
Klar kannst Du Dir auch das Modul bei Ebay fertig kaufen.
Dein zweiter Link ist ein völlig anderes Modul und erzeugt zusammen mit einem PI quasi eine CCU3. Die geht zwar auch für Homematic, ist aber eine völlig andere Welt. Es ist keine Alternative für CUL_HM zu den beiden IOs von denen ich gesprochen habe. CUL_HM unterstützt keine CCU
Gruß Otto
Nochmal von vorne:
- Der Temp/Hum.-Sensor steht auch nach mehr als einer Stunde immer noch bei "set_...."
- Ich lösche alle pending CMDs
- Ich setzt VCCU auf HMPairForSec 600.
- Ich drücke den PAIR-Button am Sensor für 1-2 sec. und sehe im Log:
2019.09.23 11:17:31 3: CUL_HM set VCCU hmPairForSec 600
2019.09.23 11:17:40 3: Device HM_621C37 added to ActionDetector with 000:10 time
2019.09.23 11:17:40 3: CUL_HM pair: HM_621C37 THSensor, model HM-WDS40-TH-I-2 serialNr
und in hminfo sehe ich
protoEvents send to devices done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
HM_621C37 : done | - | 6 | - # - | - | - | -
HM_64AA00 : done | - | 192 | - # - | - | - | -
HM_6C9924 : done | - | 34 | 9 # 16 | 3 | - | -
HM_6C9937 : done | - | 48 | 15 # 24 | 5 | - | -
========================================================================================================
sum 0 |0 |280 |24 #40 |8 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : none
status request :
autoReadReg wakeup : HM_621C37
status request wakeup:
autoReadTest : HM_621C37
IODevs:culOFF:Initialized condition:-
Der Sensor sagt aber:
R-pairCentral set_0xZZZZZZ 2019-09-23 11:17:40
...ist also nicht komplett gepaired, oder?
richtig ist nicht gepairt, aber der Vorgang hat begonnen. Du brauchst also nur noch getConfig machen und musst wieder den configtaster drücken bzw warten dass er die Daten überträgt.
Deine VCCU hat die HMId ZZZZZZ ? ???
OK, getConfig und kurz auf den Knopf am Sensor gedrückt:
R-pairCentral 0xZZZZZZ 2019-09-23 11:40:44
sowie in hminfo:
configCheck done:
templist mismatch
HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
STRIKE! Das hat diesmal geklappt, oder? :-D
Dann könnte ich als nächstes den Temp/Hum-Sensor mit dem Heizkörperventil peeren... Oder spricht da etwas dagegen?
Ja. Du musst bei dem Sensor immer den Configtaster kurz drücken, der überträgt nicht von selbst.
Zitat von: claudio-fhem am 23 September 2019, 11:43:16
Dann könnte ich als nächstes den Temp/Hum-Sensor mit dem Heizkörperventil peeren... Oder spricht da etwas dagegen?
Könntest Du. Ich würde an Deiner Stelle erstmal das Thema mit den tempList.cfg abarbeiten, d.h. Deine Liste vollständig eintragen und sichern oder eine Liste erstellen und importieren. Du weißt ja jetzt wo sie liegt und wie es geht. ;)
Was ich schon lange fragen wollte: Warum hast Du eigentlich (ich find den nicht hübsch) Sensor genommen und nicht den Wandthermostaten? Die Kosten sind gleich und der Wandthermostat hat vor allem für Dich doch viel mehr Funktionen?
Hmmm, die INFO
Zitat von: Otto123 am 23 September 2019, 11:46:07
Ja. Du musst bei dem Sensor immer den Configtaster kurz drücken, der überträgt nicht von selbst.
...hätte mir ja auch gestern abend schon weitergeholfen :-D
Zum Sensor: Ich wollte erstmal flexibel bleiben (ob der Sensor beim Heizkörperventil notwendig und gut ist wollte ich auf jeden Fall zuerst probieren), wenn ich ihn nicht für das Heizkörperventil brauche, kann ich ihn an unterschiedlichsten Stellen im Raum/Haus aufstellen. Ich missbrauche solche Geräte (433 MHz) auch schon seit Jahren im Outdoor-Einsatz (Regengeschützt, unter einem großzügigen Dachüberstand von mehr als 1 m...) ohne Verschleiss...
Zitat von: claudio-fhem am 23 September 2019, 12:29:45
Hmmm, die INFO
...hätte mir ja auch gestern abend schon weitergeholfen :-D
Ja sorry. Es ist generell so, dass man die Datenübertragung bei allen "nicht Aktoren" / Sensoren anstossen muss. Leider ist die Art und Weise
WIE praktisch bei jedem anders. Configtaster geht immer (aber immer "anders"), manche machen lazy config (verzögert von selbst) machen kann man auslösen (Bewegungsmelder) manche darf man
nicht auslösen (Fenstersensoren)
Der Wandthermo hat nur einen "Nachteil" er verbraucht mehr Batterie (Wechsel weniger als einmal im Jahr). Dafür zeigt er die Temperatur auch direkt an. Deshalb nehme ich im Zimmer immer den.
Der andere Sensor funktioniert Jahrelang ohne Batteriewechsel.
Die 433 MHz Funkthermometer/Hum. Einheiten haben auch nur 2x AAA und da ist man auch jährlich beim Batteriewechsel dabei. Daher bin ich froh, dass das HM-Dings 2x AA hat und (wenn auch hübsch hässlich) doch hoffentlich 2 Jahre schafft (wie auch der Heizkörperthermostat? Oder sollte man den vor jeder Heizsaison neu bestücken?).
Wenn sich das externe Thermometer für den Heizkörper bewährt, kann ich immer noch so ein Wandgehänge schiessen...
Was ist lazy config?
PS: Ich hatte überlegt, dem fhem Raspi noch einen USB-stick zu verpassen, um die SD-Karte zu schonen. Ist das Auslagern der Log-Dateien viel Aufwand? Rentiert das? Ich habe Sandisk Karten, davon habe ich bisher auch über längere Zeiträume noch keine kaputt bekommen, aber halt auch noch keine Erfahrung mit fhem und seinen Schreibzugriffen...
https://www.google.de/search?q=site:forum.fhem.de+lazy+config
USB Stick ist witzlos, das ist die gleiche Technik, also nicht besser als SD Karten.
Ich betreibe FHEM auf mehreren Raspis, bei mir ist noch keine SD Card gestorben.
Mein HM-WDS40-TH-I läuft seit Januar 2016 mit dem ersten Satz. Aber nur als Messer nicht als Peer :)
Witzlos nicht ganz, wenn die Karte read-only geht kann sich der Raspi verabschieden, wenn der USB-stick read-only geht nur fhem (oder nur das logging?)...
Ja, die AA sind schon wesentlich ergiebiger, als die AAA Batterien... Bei peering mit dem Funkthermostat verbraucht der Sensor mehr? Ich dachte, der Heizkörperthermostat "liesst dann einfach mit" und betrachtet die Temperatur als für sich relevant?
Wer weiß schon durch welchen Prozess auf dem Raspi welches Speichermedium so belastet wird, dass es kaputt geht. :-\
Deshalb: Datensicherung und fertig :) Wenn das System "Lebenskritisch" ist, muss andere Hardware verwendet werden. ;)
Ich habe nicht gesagt, das er als Peer mehr verbraucht. Ich habe es nur nicht so in Betrieb.
Und ich weiß auch nicht, wie aufwendig die Temperatur vom Sensor wirklich übermittelt wird. Normalerweise wird die Meldung des Sensors von der Zentrale und vom Peer quittiert.
Ob das zu mehr Funkverkehr beim Sensor führt? Ob das Batterie relevant ist? :-\
Keine Ahnung. ;D
Leicht OT: Was machst du mit dem Zero W bei fhem? Ich habe noch einen zero übrig, den ich gerne auf mein mini-fhem mit den paar HM-Geräten ansetzen würde (dümpelt in htop ja immer nur bei ein paar Prozent CPU-Last). Spricht da was dagegen?
Nö, was sollte dagegen sprechen?
Mein ZeroW hat ne Kamera an Board und soll auf Kommando Bilder schießen und BT Anwesenheit machen. Auch FHEM läuft darauf prima. Ist bei mir aber immer noch in der Bastelphase :)
Hmm. Dann wäre aber ein HM-Hütchen doch ganz sinnvoll. Dann braucht's keinen USB-Hub (powered?). Einfach USB-RJ45 mit OTG-Kabel an den Zero...
Aber vielleicht sollte ich erstmal ein paar Wochen mit dem 2er fahre und konfigurieren und meine erst Grafik erstellen. Und ein Zeitprogramm für die eine Schaltsteckdose erstellen.
Und ein zweites Programm in das Heizkörperventil reindrücken (für Abwesenheit...). Tausend Sachen zu machen....
Keep ist simpel :)
Wenn LAN und HM-MOD-RPI-PCB dann eher direkt so https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler
Aber mach doch erstmal mit dem was Du hast. Der CUL schafft es ja offenbar :)
Eine Frage noch zum Heizkörperventil. Da sehe ich unter _Clima:
state T: 21.7 desired: 21.0 valve: 23
1. ist "23" für valve irgend eine arbiträre Einheit oder heisst das "23% offen"?
2. Wenn die Temp über der Solltemp ist, warum ist das Ventil überhaupt (schon) offen? :-)
Irgendwie läuft das Heizkörperthermostat nicht wie gedacht.
Ich habe in device info long einen Sollwert von 20.0°C und in Clima Readings "control mode manual", aber eigentlich sollte das doch dem eingegeben Programm folgen und dort ist der Sollwert niemals 20.0, sondern 18 oder 21°C. Bis gestern stand das da auch immer über Tag so (Sollwert 21°C).
Device name:HM_64AA00
org ID :0095 Model=HM-CC-RT-DN
alias ID :0095 Model=HM-CC-RT-DN
mode :config,wakeup,burstCond - activity:alive
protState : CMDs_done pending: none
HM_64AA00_Weather state:22.4
HM_64AA00_Climate state:unpeered
HM_64AA00_WindowRec state:last:trigLast
HM_64AA00_Clima state:T: 22.4 desired: 20.0 valve: 0
HM_64AA00_ClimaTeam state:unpeered
HM_64AA00_remote state:unpeered
"Desired 20.0" passt aber nicht zum Programm, das ich eingestellt habe.
Und unter Clima als Readings habe ich als Programm:
R-boostPos
80 %
2019-09-22 19:20:10
R-btnNoBckLight
off
2019-09-22 19:20:10
R-dayTemp
21 C
2019-09-22 19:20:10
R-daylightSaveTime
on
2019-09-22 19:20:10
R-modePrioManu
all
2019-09-22 19:20:10
R-modePrioParty
all
2019-09-22 19:20:10
R-nightTemp
17 C
2019-09-22 19:20:10
R-noMinMax4Manu
off
2019-09-22 19:20:10
R-regAdaptive
on
2019-09-22 19:20:10
R-showInfo
time
2019-09-22 19:20:10
R-sign
off
2019-09-22 19:20:06
R-tempOffset
0.0K
2019-09-22 19:20:10
R-valveOffsetRt
0 %
2019-09-22 19:20:10
R-winOpnBoost
off
2019-09-22 19:20:10
R_0_tempListSat
07:00 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_1_tempListSun
07:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_2_tempListMon
06:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_3_tempListTue
06:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_4_tempListWed
06:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_5_tempListThu
06:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_6_tempListFri
06:30 18.0 22:00 21.0 24:00 18.0
2019-09-22 23:20:25
R_tempList_State
verified
2019-09-22 23:20:25
ValvePosition
0
2019-10-03 08:07:34
boostTime
-
2019-10-03 08:07:34
controlMode
manual
2019-10-03 08:07:34
desired-temp
20.0
2019-10-03 08:07:34
measured-temp
22.4
2019-10-03 08:07:34
partyEnd
-
2019-10-03 08:07:34
partyStart
-
2019-10-03 08:07:34
partyTemp
-
2019-10-03 08:07:34
state
T: 22.4 desired: 20.0 valve: 0
2019-10-03 08:07:34
Hat da ein Benutzer am Ventil rumgedrückt? Kann ich das Ventil wieder auf "Programm" setzen via FHEM?
Also durch Erhebung einschlägigen Beweismaterials ist relativ sicher, dass da einer der üblichen Verdächtigen am Ventil rumgedrückt hat. Wie bekomme ich das Ventil wieder unter Programmkontrolle (bin nicht vor Ort die nächste Zeit...)?
Kann man die Bedienelement am Ventilkopf per FHEM stillegen?
Tausend Dank vorab...
Controlmode manual: du musst manuell die Temp einstellen
Controlmode auto: Wochenprogramm läuft
Bedienungsanleitung gelesen? ;)
Du musst einfach nur auf auto schalten...
Gruß, Joachim
Jau, hab ich mittlerweile auch gemacht und ist auch durchgegangen... :-)
Danke für die Antwort!
Gibt es die Möglichkeit, die Tasten am Ventil stillzulegen? :-)
OK, Tastensperre im Wiki gefunden... Sorry, war etwas kopflos wegen der 1. "Störung" im System...
Ja, Tastensperre... ;)
Steht nicht nur im Wiki, steht auch in der Bedienungsanleitunh... ;)
Kein Problem, Kopflos kommt vor... ;)
Was du (soweit ich weiß) nicht verhindern kannst ist, dass manuell (neben dem auto Programm) jemand "optimiert"... ;)
Gruß, Joachim
"optimiert" = am Rädchen dreht und damit die Solltemperatur verstellt?
Im wiki liesst sich
Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden.
als sei "btnLock on" geeignet, das Handrad stillzulegen...
Ich habe versucht mit
get param btnLock
den Status auszulesen, bekomme aber als Antwort "undefined". Wie kann man den Status der Tastatursperre auslesen? :-)
Beim "Haupt-Device" get DevName regTable
EDIT: damit bekommst du ALLE Register. Mit get DevName regVal RegName kannst du auch einzelne Register lesen. Also get HTName regVal btnLock sollte gehen...
EDIT2: get regTable funktioniert nat. auch bei Kanälen. Nur sind es dann halt andere Register ;) Ich stelle expert auf 1_allReg und damit sehe ich alle Register...
Oder bei expert 1_allReg setzen, dann werden alle Register angezeigt
Setzen, da es ein Register ist mit:
set DevName regSet btnLock on bzw. globalBtnLock
Ich weiß jetzt nicht welcher Lock was lockt...
...und wundere mich ein wenig darüber, dass man auch das Stellrad locken kann...
...aber wenn's in der Anleitung im Wiki steht ;)
Aber evtl. mal in der Bedienungsanleitung querchecken...
Gruß, Joachim
Ah, vielen Dank!
Bei der Gelegenheit habe ich gesehen, dass am Thermostatventil burstRx auf ON ist. Sollte laut wiki per default OFF sein, da habe ich aber nicht dran rumgespielt.
Ich habe keinen Fenterkontakt (bisher), also kann ich doch problemlos auf OFF schalten, oder?
Zusatzfrage: Demnächst ist ja Umstellung Winterzeit, bekommt das Ventil die Zeit automatisch von fhem geliefert oder muss ich da was umstellen?
Wenn richtig gepaired (und davon gehe ich mal aus, sonst könntest du nicht an den Registern schreibend "rumspielen" ;) ), dann sollte die Zeit von fhem kommen (bin nicht sicher wie oft, glaube 1x am Tag, frag mich jetzt nicht wann genau ;) / daher nicht gleich bei der Umschaltzeit kucken gehen ;) ).
Ich habe einige (bei meiner Freundin) mit burst on laufen.
Es soll Batterie "kosten", konnte ich aber noch nicht feststellen, also Vergleich mit und ohne burst...
Ich habe das dort, da ich zwar Fensterkontake habe aber aus bestimmten Gründen die Erkennung/Steuerung über fhem mache und damit dann die Temp im Thermostat sofort geschaltet wird habe ich burst auf on...
Ansonsten kann es halt bis zu 3min dauern...
Gruß, Joachim
OK, dann lass ich das mal an und schau, wie lange die Batterien im Thermostat halten. Sicher länger als eine Saison, oder?
Ich bin noch unschlüssig wegen der Fensterkontakte. An einigen Stellen geht nur der Magnetkontakt. An anderen hätte ich die Wahl zwischen den optischen im Rahmen und den Magnetkontakten. Was ist vorzuziehen aus der Sicht der Zuverlässigkeit und Komfort etc.? Die Magnetkontakte sind sicher optisch dominanter, aber an machen Stellen kein Problem...
Die Batterien halten schon einige Zeit, kommt natürlich auch auf andere Faktoren an (z.B. wie häufig ein Fenster geöffnet wird, wie das Regelungsverhalten eingestellt ist usw.).
Zur Info: Ich plane, das direkte peering zwischen den FK's und den Thermostaten (dort, wo das noch so ist), wieder zu ändern und auf indirekt umzustellen. Denn z.B. im Sommer ist es dem Thermostat völlig egal, ob das Fenster offen ist, und häufig habe ich zwei oder mehr Fenster, die einen oder zwei Thermostaten "bedienen"; zudem kann man das dann beliebig verzögern (es bringt wenig, wenn der Thermostat während eines echten Stoßlüftens direkt abregelt; erst, wenn das Fenster dauerhaft offen ist, ist das was anderes). Das reduziert den Funkverkehr und - tendenziell -auch die "Arbeit" für den Aktor.
Damit bist du uU. unabhängig vom Hersteller (die HM-Kontakte sind alle nicht sonderlich hübsch, ich habe meistens die Drehgriff-Variante im Einsatz), dafür muß halt FHEM zuverlässig laufen (was es bei mir bisher tat). Bei einem HK ist es zwar nicht toll, wenn er gg. das offene Fenster heizen darf, aber die Welt geht deswegen nicht gleich unter.
Just my2ct.
Aha, ich sollte also Fensterkontakte von einem anderen Hersteller hernehmen (gibtz Vorschläge :-) ? ) und dann fhem das Heizkörperventil abschalten lassen?
Bei der Batterielebensdauer mache ich mir eher Sorgen um die Heizkörperventile, dass die nicht mitten im Winter den Geist aufgeben, wenn ich nicht da bin... Sollte man alle 2 Jahre im Herbst die Batterien tauschen? Die Spannung (sehe ich in fhem) sinkt ja erst wirklich ganz am ENDE der Lebensdauer, oder?
Also ich musste (seit ich protokolliere ;) ) erst bei einem HKT die Batterien wechseln und das nach knapp 3 Jahren, genau waren es 145 Wochen ;)
Ich habe beide Fensterkontakte.
Hmmm, ist nur subjektiv aber:
die Batterien in den magnetischen halten (deutlich) länger (zumindest gefühlt) [ohne Protokollierung: magnetischer an der Balkontür, also im Sommer öfter auf/zu und nat. tägl. lüften ca. 2-3 Jahre / ein optischer bei meiner Freundin am Fenster des Kinderzimmers, also nur lüften etc. hat sich jetzt mal nach so knapp 2 Jahren gemeldet]
dafür sind es 2 Batterien und nicht so "gängig", die für die optischen bekommt man ja überall...
wie du schon erkannt hast ist bei den magnetischen der Aufwand für Anbringung größer und ja es hängt halt auch immer was am Fenster und am Rahmen...
Allerdings gibt es für die optischen einen Bausatz (wie auch für einiges andere): https://de.elv.com/elv-homematic-komplettbausatz-funk-tuer-fensterkontakt-optisch-hm-sec-sco-fuer-smart-home-hausautomation-131632
(etwas löten: Batteriekontakte und Funkmodul [glaube ich] / bei den HKT- und den Wandthermostat-Bausätzen muss gar nicht gelötet werden, nur zusammenstecken und schrauben)
was mich dazu gebracht hat die Fenster bei meiner Freundin und meine Türen mit dem optischen auszustatten...
...und die auch als "Platform für andere Spielereien" zu nutzen ;)
Gruß, Joachim
Zitat von: claudio-fhem am 04 Oktober 2019, 10:52:12
Aha, ich sollte also Fensterkontakte von einem anderen Hersteller hernehmen (gibtz Vorschläge :-) ? ) und dann fhem das Heizkörperventil abschalten lassen?
Nach Vorschlägen fragen ist immer so eine Sache ;)
Aktuell habe ich nur Homematic und einen Strip mit ZWave, den aber, weil der außen im Freien hängt ;)
Wenn du Vorschläge willst ist es besser zu suchen und/oder einen neuen Thread aufzumachen...
...hier kommen vermutlich nicht viele vorbei mit Vorschlägen... ;)
Ein anderer Hersteller heißt meist (und in dem Fall auf jeden Fall) einen zusätzlichen Funkempfänger/sender...
...und einarbeiten in ein anderes fhem-Modul.
Weil da jedes so seine eigene "Philosophie" hat (manchmal auch wegen anderer "Philosophie" der Technologie)...
Zitat von: claudio-fhem am 04 Oktober 2019, 10:52:12
Bei der Batterielebensdauer mache ich mir eher Sorgen um die Heizkörperventile, dass die nicht mitten im Winter den Geist aufgeben, wenn ich nicht da bin... Sollte man alle 2 Jahre im Herbst die Batterien tauschen? Die Spannung (sehe ich in fhem) sinkt ja erst wirklich ganz am ENDE der Lebensdauer, oder?
Dafür habe ich das hier: https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514
Die Wandthermostate und HKTs liefern ja auch die aktuelle Spannung...
...und nicht erst low wenn es (fast) zu spät ist...
Gruß, Joachim
Ja, Empfehlungen sind so eine Sache...
Kommt auch auf's Umfeld an. Ich habe z.B. (v.a.) bei der Beleuchtung sehr gute (erste) Erfahrungen mit ZigBee gemacht, wohne aber auch auf dem Land, da gibt' nicht viel Verkehr auf 2.4GHz.
Du brauchst für FK's dann aber ein Interface, das Änderungen direkt durchstellt (z.B. ConBee II iVm. deCONZ oder zigbee2mqtt).
Und ja, man muß sich einarbeiten, aber wenn du z.B. in Richtung Beleuchtung was tun willst, wäre das mMn. echt anzuraten und ist mit deCONZ auch recht einfach zu handhaben (eher noch deutlich einfacher als CUL_HM).
Was die Batterien angeht: die halten sogar dann noch eine ganze Weile, wenn sie als "leer" gemeldet werden, da ist also in der Regel keine Eile angesagt.
Bzgl. Beleuchtung kann ich Beta-User nur zustimmen.
Da bin ich auch eher bei ZigBee (deCONZ / RaspBee von Dresden Elektronik [ist finde ich das "fhem für ZigBee" ;) ] / habe auch noch das Tradfri Gateway: auch gut und in fhem sehr gut integriert aber nicht so gut mit "Fremdleuchten" ;) )...
...das einzige was mir fehlt sind "Lichtschalter" bzw. Sender die man "unter/hinter" vorhandene Schalter anschließen kann.
Die Schalter die es gibt (Osram, Philips, ...) sind alle sehr weit weg von meinen Schalterprogrammen...
...daher bin ich grad dabei eine Tradfri-FB als Schalter umzubauen.
Was noch geht ist wohl den Philips oder war es Osram in einen Gira EnOcean-Schalter einzubauen (also "Innerei" zu tauschen / aber dann ganz schön teuer)...
Und ich habe nicht überall Nulleiter in den Schalterdosen :-|
Daher habe ich nun auch häufiger EnOcean, da gibt es Schalter ganz ohne notwendige Anschlüsse: autark. Der kann dann überall hin :)
Und ja, selbst wenn die magnetischen FKs schon (lange) leer anzeigen, laufen die immer noch gefühlt "Monate" ;)
Die optischen sind da kritischer, die sind bei low schon nach ein paar Tagen (max. so 1-2 Wochen) dann echt leer -> dead
Gruß, Joachim
Ihr seid alle schon 2-3 Schritte voraus... Ich kann nicht mal eine einfache Grafik (Raumtemp, Hum.) derzeit erstellen ;-)
Oder eine Zeitschaltuhr, die ab Sonnenuntergang eine der HM-Schaltsteckdosen (mit etwas Zufall auf der Einschaltzeit) für eine zufällige Zeit von 4-7 Stunden einschaltet.
Bin ich da hiermit auf der richigen Spur:
https://wiki.fhem.de/wiki/RandomTimer
Oder eher was anderes?
Was die Grafik angeht, sollten sich die notwendigen Schritte z.B. aus dem Quick-Start ergeben, aber ohne input kein output.
RandomTimer schaltet innerhalb des Intervalls auch schon mal zufällig aus und wieder ein... Scheint nicht das zu sein, was du suchst.
Dafür würde ich eher ein "einfaches at" nehmen. Fang' mit "sunset" zum Einschalten an und mit einer via Zufallsfunktion generierten "on-for-timer"-Dauer für das Ausschalten ;) . (Ohne eigenen Code-Versuch kein weiterer support...)
...ja, ick versuchs.... nebenbei das Auto abgestorben und und und und...
tbc...
Nachgeschobene Frage zu den HM Schaltsteckdosen
https://wiki.fhem.de/wiki/HM-LC-Sw1-Pl2_Funk-Zwischenstecker-Schaltaktor_1fach
Ich habe den Eindruck, die Dinger sind nach stromlos machen (rausziehen, vermutlich auch Stromausfall?) grundsätzlich OFF, wenn die Spannung wieder anliegt, stimmt das? (Habe es gerade nochmal probiert, hier ist das so...)
Kann ein Problem geben, wenn ein angeschlossenes Gerät nach einem Stromausfall nicht wiederkommt, weil die Steckdose aus ist. Kann man da was drehen, dass die Steckdose grundsätzlich in den Modus VOR Stromausfall zurückkomt? :-)
Kann schon sein. Müßte in den Registern zu sehen und ggf. zu ändern sein (siehe Anhang zum Einsteiger-pdf), evtl. mußt du "invisible"-Register erst sichtbar machen (näheres steht in der Doku, ich müßte auch suchen).
Moin,
die Powermeter Steckdosen haben im switch channel ein Register:
ZitatNo regs found for:
PSD1_Sw type:powerMeter -
list:peer register :value
1: powerUpAction :off
1: sign :off
1: statusInfoMinDly :2 s
1: statusInfoRandom :1 s
1: transmitTryMax :6
Das kann man setzen, steht aber per Standard auf off. Aber auch da geht nur on oder off - also letzer Zustand geht nicht.
Zitat1: powerUpAction | literal | | on: simulate short press of peer self01 (self02 if dual buttons) after power up options:off,on
Generell ist es ein Problem Zustände zu "merken", weil die verbauten eeproms nur eine begrenzte Anzahl Schreibzyklen haben.
Bei Stromausfall kannst Du auf global:INTIALIZED einen Trigger setzen und die gewünschten Zustände wieder herstellen. Im laufenden Betrieb müsstest Du an kritischen Stellen gegen mutwilliges Steckdose ziehen eine Überprüfung einbauen.
Da haben einige/fastAlle? HM Geräte ein powerOn Reading was man auswerten könnte.
Gruß Otto
Danke für die raschen Antworten!
Ich habe auf der Statusseite der Schaltsteckdose
R-powerUpAction off
Kann ich mit
set HM_name R-powerUpAction on
was erreichen oder verstehe ich das komplett falsch?
OK, frag das Wiki:
set <deviceName>_Sw regSet powerUpAction on
Ick teste...
...funzt...
..also: funzt, bis auf 2 Schaltsteckdosen, die dieses R-power reading gar nicht haben, da bekomme ich als Fehler:
cannot calculate value. Please issue set HM_70CXXX getConfig first - invalid
Und das vorgeschlagene getConfig änder nichts.
Bei beiden, die nicht funktionieren, beginnt die HM-Kennung mit "HM_70C...", sind die irgendwie anders/neuer?
PS: Nach dem dritten "set getConfig" hat'S gefunzt...
Habe jetzt überall
R-powerUpAction set_on
Korrekt?
Wenn ich es richtig verstehe, habe ich den Parameter direkt in die Schaltsteckdose geschrieben und da im EEPROM, überlebt das auch das Herausziehen der Steckdose/stromlos machen für einige Zeit. Und aus dem selben Grund kann ich das nicht in der config von fhem speichern?
Welcher Ty ist es genau!?
Welche FW!?
Richtig gepaired!?
Ein list würde (uns) helfen... ;)
Gruß, Joachim
Danke für die Antwort, mit mehr Geduld habe sie alle getunt. bleibt nur noch meine letzte Frage aus dem Edit... ;-)
Generelle Anmerkung:
Erst RTFM, dann fragen wäre für uns alle einfacher... Andersrum ist es so, dass jedenfalls ich irgendwann keine Lust mehr habe, den ganzen Edits zu folgen.
Zitat von: claudio-fhem am 29 Mai 2020, 10:13:27
Habe jetzt überall
R-powerUpAction set_on
Korrekt?
Wenn ich es richtig verstehe, habe ich den Parameter direkt in die Schaltsteckdose geschrieben und da im EEPROM, überlebt das auch das Herausziehen der Steckdose/stromlos machen für einige Zeit. Und aus dem selben Grund kann ich das nicht in der config von fhem speichern?
Nicht korrekt. Vermutlich hilft "getConfig", um "Vollzug" zu sehen. (Ist das immer noch der CUL? Dann könnte es sein, dass Meldungen verloren gehen).
Es macht auch keinen Sinn, Dinge in der Config zu speichern, die woanders "hart" stehen (auf der hardware gespeichert!). Da macht nur das Lesen Sinn (=getConfig) ;) . Und "Lesen" ergibt eben Readings oder Internals, aber nichts, was man in der config speichert....
OK, dazu wird nix im FM stehen, denke ich: :-)
Ich habe 2 raspis mit HM-CUL im selben Raum stehen, aus bestimmten Gründen sind die getrennt. Schon beim Anlernen diverser Schaltsteckdosen an dem 2. raspi habe ich festgestellt, dass plötzlich an dem 1. raspi 2 von den Schaltsteckdosen im Raum HM_CUL auftauchten, obwohl diese Installation NIE in den den Anlernmodus versetzt wurde.
Auch beim Schreiben des set regSet heute morgen ist eine Schaltsteckdose plötzlich als Device in der anderen fhem GUI aufgetaucht.
Darf das sein? oO
Das steht nicht im FM, aber dutzendfach hier im Forum, weil es ebenfalls eine "typische" Einsteigerfrage ist (falls der Nachbar ebenfalls HM einsetzt). "Man" hätte es also durch entsprechende Suche finden können...
Kurzform der Antwort:
Es ist Funk, daher kann das jedes taugliche IO mitlesen, und autocreate legt dann eben an, was das IO sieht...
(Und ja: jedes taugliche IO kann auch Anweisungen senden, vorausgesetzt, es ist autorisiert, was in der Regel nur heißt, dass die HmID passen muss ;) . Gegenmaßnahme: AES (was aber nur bedingt "in der Fläche" zu empfehlen ist).)
...ich würde eher dieses autocreate abschalten, logisch betrachtet...
...was auch immer du mit dieser Information anfangen willst... (ich verstehe die Rückmeldung nicht; das Abschalten von autocreate mag dagegen helfen, dass du Infos zu den getrennten Installationen nicht in beiden siehst, aber "that's it", und ob die ganze Konstruktion mit den 2 FHEM Sinn macht, ist damit auch nicht gesagt, aber das scheint ja so sein zu müssen).
Weitere Stichworte jedenfalls: VCCU und ignore...
(Auch das sind Grundlagen zu CUL_HM; also lies v.a. einfach mal in Ruhe, was du zum Thema VCCU findest).
Zitat von: Beta-User am 29 Mai 2020, 16:07:58
Weitere Stichworte jedenfalls: VCCU und ignore...
Aber dann eigentlich nur mit "getrennten" also nicht identischen HMIDs der beiden VCCUs/Zentralen.
Hello again!
Ich habe mittlerweile noch einen fhem raspi 2 an einem anderen Standort, das integriert primär 2 pilight Instanzen (läuft seit letztem Jahr einwandfrei), hat aber auch einen CUL (mit VCCU), der Homematic spricht.
Daran habe ich gestern eine von meinen Schaltsteckdosen angelernt (erstes Homematic-Gerät an dieser Installation).
2021.08.14 14:32:49 1: CUL_HM Unknown device HM_6859AF is now defined
2021.08.14 14:32:49 3: CUL_HM received config CCU:vccu device: HM_6859AF. PairForSec: on PairSerial:
2021.08.14 14:32:49 3: CUL_HM pair: HM_6859AF switch, model HM-LC-SW1-PL-DN-R1 serialNr PEQ1449713
2021.08.14 14:32:54 3: CUL_HM received config CCU:vccu device: HM_6859AF. PairForSec: off PairSerial:
2021.08.14 14:33:00 3: CUL_HM set HM_6859AF statusRequest noArg
2021.08.14 14:33:04 3: CUL_HM set HM_6859AF getConfig noArg
2021.08.14 14:33:58 3: CUL_HM set HM_6859AF off noArg
2021.08.14 14:34:02 3: CUL_HM set HM_6859AF on noArg
2021.08.14 14:34:31 3: CUL_HM set HM_6859AF off noArg
2021.08.14 14:37:15 1: RMDIR: ./restoreDir/save/2021-01-30
2021.08.14 14:39:13 3: CUL_HM set HM_6859AF getConfig noArg
2021.08.14 14:43:52 3: CUL_HM set HM_6859AF off noArg
2021.08.14 14:43:56 3: CUL_HM set HM_6859AF on noArg
Das Gerät ist gepairt und ich kann aus der GUI schalten
Device name:HM_6859AF
mId :0002 Model=HM-LC-SW1-SM
mode :normal
protState : CMDs_done pending: none
configuration check: updating
Configuration check updating habe ich seit gestern nachmittag, außerdem wurde kein Logfile (in der GUI?) angelegt. Ich hab dann ein LogFile erzeugt, Typ text, aber wenn ich auf "text" geklickt habe, wurde immer ein SVG-plot angezeigt, daher habe ich das Device (LogFile) wieder gelöscht.
Danach fiel mir auf, dass das GENERELLE Logfile aus der GUI verschwunden ist (normalerweise links über "Commandref). In /opt/fhem/log kann ich das log für August aber lesen.
Ich hatte gestern versucht, die Schaltsteckdose automatisch auf "AN" zu setzen, nach power loss:
2021.08.14 15:20:33 3: CUL_HM set HM_6859AF regSet exec powerUpAction on
2021.08.14 15:20:37 3: CUL_HM set HM_6859AF getConfig noArg
2021.08.14 15:22:27 3: CUL_HM set HM_6859AF regSet exec powerUpAction on
2021.08.14 15:25:19 3: CUL_HM set HM_6859AF regSet exec powerUpAction on
aber mit "getConfig" bekomme ich (anders als auf meinen anderen fhems mit CUL und VCCU und er selben Sorte Homematich Schaltsteckdose) keinen Parameter dafür angezeigt.
Egal ob ich in der GUI oder der Kommandozeile versuche, "getConfig" zu machen, es kommt scheinbar nichts zurück von der Schaltsteckdose:
2021.08.15 11:46:49 3: CUL_HM set HM_6859AF getConfig noArg
2021.08.15 11:47:09 3: CUL_HM set HM_6859AF getConfig noArg
Was mache ich falsch? :-(
______
PS: Raspi (Raspbian Buster light) und FHEM hatte ich heute morgen nacheinander upgedated, so sah danach der Start von fhem im log aus:
Server shutdown
2021.08.15 11:33:21 1: Including fhem.cfg
2021.08.15 11:33:22 3: WEB: port 8083 opened
2021.08.15 11:33:22 2: eventTypes: loaded 458 lines from ./log/eventTypes.txt
2021.08.15 11:33:22 3: Opening CULgb1 device /dev/ttyUSB0
2021.08.15 11:33:22 3: Setting CULgb1 serial parameters to 38400,8,N,1
2021.08.15 11:33:25 3: CULgb1: Possible commands: ABbCEeFfGhiKklMmRTtUVWXxYz
2021.08.15 11:33:25 3: CULgb1 device opened
2021.08.15 11:33:25 2: Switched CULgb1 rfmode to HomeMatic
2021.08.15 11:33:28 3: Opening pili1 device 10.10.10.107:5000
2021.08.15 11:33:28 3: piliGB device opened
2021.08.15 11:33:29 3: Opening pili2 device 192.168.100.107:5000
2021.08.15 11:33:29 3: piliOrp device opened
2021.08.15 11:33:29 1: Including ./log/fhem.save
2021.08.15 11:33:29 0: Featurelevel: 6
2021.08.15 11:33:29 0: Server started with 24 defined entities (fhem.pl:24810/2021-07-29 perl:5.028001 os:linux user:fhem pid:484)
2021.08.15 11:33:34 1: CUL_HM start inital cleanup
2021.08.15 11:33:34 1: PERL WARNING: substr outside of string at ./FHEM/10_CUL_HM.pm line 10697.
2021.08.15 11:33:34 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/10_CUL_HM.pm line 10697.
2021.08.15 11:33:34 1: PERL WARNING: Use of uninitialized value $a[2] in uc at ./FHEM/10_CUL_HM.pm line 571.
2021.08.15 11:33:34 1: define vccu_Btn0 CUL_HM : wrong syntax: define <name> CUL_HM 6-digit-hex-code [Raw-Message]
2021.08.15 11:33:34 1: CUL_HM finished initial cleanup
OK, mit einem beherzten
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
habe ich den logFile wieder in die GUI katapultiert. Aber wie bekomme ich für die Schaltsteckdose ein eigenes log, wenn es nicht miterstellt wurde?
define FileLogDeviceName FileLog ./log/LogdateiName-%Y-%m.log DeviceName:RegEx
attr FileLogDeviceName logtype text
Siehe commandref...
EDIT: Das noArg kannst du ignorieren, gibt Threads im Forum. Nachdem er sich schalten lässt, ist er wohl tatsächlich gepaired. Ansonsten würden entsprechende lists der Devices weiterhelfen...
Warum einen CUL für Homatic, wenn man ein neues/weiteres System aufsetzt?
Ist und bleibt mir ein Rätsel...
Gruß, Joachim
Zitat von: MadMax-FHEM am 15 August 2021, 16:19:07
define FileLog ./log/LogdateiName-%Y-%m.log DeviceName:RegEx
attr FileLogDeviceName logtype text
Siehe commandref...
EDIT: Das noArg kannst du ignorieren, gibt Threads im Forum. Nachdem er sich schalten lässt, ist er wohl tatsächlich gepaired. Ansonsten würden entsprechende lists der Devices weiterhelfen...
Warum einen CUL für Homatic, wenn man ein neues/weiteres System aufsetzt?
Gruß, Joachim
Tausend Dank für die Antwort! :-)
Ah, das Problem war, dass ich mit dem Alias definiert hatte, darauf blieb das Log leer. Mit dem HM_6859AF als device name hat es geklappt!
Jetzt bleibt nur noch das Problem mit dem
set HM_6859AF regSet exec powerUpAction onDas sehe ich im general log:
2021.08.15 16:32:49 3: CUL_HM set HM_6859AF regSet exec powerUpAction on
2021.08.15 16:33:21 3: CUL_HM set HM_6859AF regSet exec powerUpAction on
Im neuen Log für das Device ist nichts.
Ein getConf danach:
2021.08.15 16:35:34 3: CUL_HM set HM_6859AF getConfig noArgführt im Log des Device zu
2021-08-15_16:35:34 HM_6859AF commState: CMDs_pending
2021-08-15_16:35:34 HM_6859AF cfgState: updating
2021-08-15_16:35:34 HM_6859AF cfgState: updating
2021-08-15_16:35:34 HM_6859AF commState: CMDs_pending
2021-08-15_16:35:34 HM_6859AF commState: CMDs_pending
2021-08-15_16:35:34 HM_6859AF commState: CMDs_processing...
2021-08-15_16:35:34 HM_6859AF commState: CMDs_processing...
2021-08-15_16:35:35 HM_6859AF commState: CMDs_processing...
2021-08-15_16:35:35 HM_6859AF commState: CMDs_done_________________________________
Listing
Internals:
CULgb1_MSGCNT 19
CULgb1_RAWMSG A0E02A0106859AFA1B2C30100000000::-55:CULgb1
CULgb1_RSSI -55
CULgb1_TIME 2021-08-15 16:35:35
DEF 6859AF
FUUID 6117b7f1-f33f-7edf-8fff-1f0da73b94b0e347
IODev CULgb1
LASTInputDev CULgb1
MSGCNT 19
NAME HM_6859AF
NOTIFYDEV global
NR 31
NTFY_ORDER 50-HM_6859AF
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:02 - t:10 s:6859AF d:A1B2C3 0100000000
protLastRcv 2021-08-15 16:35:35
protRcv 19 last_at:2021-08-15 16:35:35
protSnd 29 last_at:2021-08-15 16:35:35
protState CMDs_done
rssi_CULgb1 cnt:10 min:-55 max:-54 avg:-54.9 lst:-55
rssi_at_CULgb1 cnt:19 min:-56 max:-54.5 avg:-55.15 lst:-55
CL:
Authenticated 0
BUF
FD 4
LASTACCESS 1629038500
NAME WEB_10.0.0.29_45678
NR 50
PEER 10.0.0.29
PORT 45678
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
READINGS:
2021-08-15 16:40:47 state Connected
READINGS:
2021-08-15 16:30:59 CommandAccepted yes
2021-08-15 11:19:41 D-firmware 2.6
2021-08-15 11:19:41 D-serialNr PEQ1449713
2021-08-15 16:35:34 IODev CULgb1
2021-08-15 16:35:34 PairedTo 0xA1B2C3
2021-08-15 16:35:34 RegL_00. 00:00 02:01 0A:A1 0B:B2 0C:C3 15:FF 18:00
2021-08-15 16:35:34 RegL_01. 00:00 08:00 30:06 56:01 57:24 93:5F 94:B3
2021-08-15 16:35:34 cfgState updating
2021-08-15 16:35:35 commState CMDs_done
2021-08-15 16:30:59 deviceMsg off (to vccu)
2021-08-15 16:30:59 level 0
2021-08-15 16:30:59 pct 0
2021-08-14 16:28:42 powerOn 2021-08-14 16:28:42
2021-08-15 16:30:59 recentStateType ack
2021-08-15 16:30:59 state off
2021-08-15 16:30:59 timedOn off
2021-08-15 16:30:59 trigLast fhem:02
helper:
HM_CMDNR 2
cSnd 01A1B2C36859AF01040000000001,01A1B2C36859AF0103
cfgStateUpdt 0
dlvlCmd ++A011A1B2C36859AF0201000000
lastMsgTm 1629038135.18578
mId 0002
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cfgChk:
cmds:
TmplKey :no:1629038447.71771
TmplTs 1629038447.71771
cmdKey 1:1:0::HM_6859AF:0002:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt ,vccu
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 0
newChn +6859AF,00,00,00
nextSend 1629038135.34447
rxt 0
vccu vccu
p:
6859AF
00
00
00
prefIO:
CULgb1
mRssi:
mNo 02
io:
CULgb1:
-49
-49
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO CULgb1
flg A
ts 1629038135.18578
ack:
HASH(0x2b06640)
028002A1B2C36859AF00
rssi:
CULgb1:
avg -54.9
cnt 10
lst -55
max -54
min -55
at_CULgb1:
avg -55.1578947368421
cnt 19
lst -55
max -54.5
min -56
shadowReg:
tmpl:
Attributes:
IOgrp vccu:CULgb1
alias HM_switch_1
autoReadReg 4_reqStatus
expert rawReg
firmware 2.6
icon 1_nuki
model HM-LC-SW1-PL-DN-R1
peerIDs 00000000
serialNr PEQ1449713
subType switch
webCmd statusRequest:toggle:on:offWarum CUL? Weil es bei den anderen beiden Installationen auch funktioniert...
PS: und in der GUI für die HM Schaltsteckdose habe ich immer noch
cfgState updating 2021-08-15 16:35:34
Kann/muss man die Steckdose irgendwie resetten?
Immer mal langsam reiten... ;)
Was stört?
Also es sieht so aus als wäre das Register doch übernommen worden?
Kein Fehler beim Ausführen und das getConfig ist doch auch durch?
Evtl. musst du das Attribut expert von rawReg auf all (oder so setzen), dann siehst du alle Register.
Oder abfragen mittels RegList/RegTable...
EDIT: oder einfach testen. Vom Strom trennen und wieder dran und sehen, ob er das gewünschte Verhalten übernommen hat ;)
Was meldet denn set hm configCheck (sofern hm HMINFO definiert ist)?
Naja: CUL ist halt nicht optimal für Homematic. Ja geht. Kann auch (für dich) auf Dauer gehen. Nur wenn es Probleme gibt (z.B. Timeout Register Read o.ä.), dann ist es meist besser/einfacher auf ein vernünftiges IO umzusteigen, als eben die Probleme zu bekämpfen.
Evtl. empfiehlt sich ein Blick auf die "Timing-FW" für den CUL, da sind Optimierungen für Homematic in die FW des CUL integriert...
Gruß, Joachim
attr ... expert allReg
gesetzt, danach abgerufen und siehe da:
R-powerUpAction on 2021-08-14 15:20:37
Hatte also schon gestern funktioniert, wurde aber nicht angezeigt. :-)
Und: Ja, es funktioniert auch, rausziehen und reinstecken, dann schaltet er auf ON nach 2 sec...
Aber immer noch:
cfgState updating 2021-08-15 11:47:09
...was immer das bedeutet.
Aktuell wird einiges an den Himematic Modulen umgebaut...
Normalerweise zeigt das an, dass eben noch Daten ausgetauscht werden.
Wobei das bei "Dauerstromern" schnell gehen sollte...
Evtl. das Attribut autoReadReg mal auf missing stellen und ein getConfig...
Oder eben configCheck mittels HMINFO...
Da sollte dann zu sehen sein, ob noch was fehlt...
Wenn da alles i.O. ist, dann einfach ignorieren...
Gruß, Joachim
...so
autoReadReg 5_readMissinggesetz und getConfig, aber immer noch
cfgState updating 2021-08-15 20:36:44obwohl im log des Device
2021-08-15_20:36:44 HM_6859AF commState: CMDs_pending
2021-08-15_20:36:44 HM_6859AF cfgState: updating
2021-08-15_20:36:44 HM_6859AF cfgState: updating
2021-08-15_20:36:44 HM_6859AF commState: CMDs_pending
2021-08-15_20:36:44 HM_6859AF commState: CMDs_pending
2021-08-15_20:36:44 HM_6859AF commState: CMDs_processing...
2021-08-15_20:36:44 HM_6859AF commState: CMDs_processing...
2021-08-15_20:36:45 HM_6859AF commState: CMDs_processing...
2021-08-15_20:36:45 HM_6859AF commState: CMDs_doneAber vielleicht ist es wirklich nicht so wichtig. Sollte mich endlich um die Programmierung als Zeitschaltuhr bemühen. Hab heute aus Verzweiflung ein paar alte Zeitschaltuhren bestellt...
Was meinst du mit
ZitatOder eben configCheck mittels HMINFO...
Tausend Dank soweit! :-)
https://wiki.fhem.de/wiki/HomeMatic_HMInfo
Gruß, Joachim
...jau, gerade drauf gestoßen! :-D
Jetzt habe ich:
cfgState ok 2021-08-15 20:51:50
nachdem ich ein
define hm HMinfo
und ein
get hm configCheck
eingeleitet habe. Schräge Sache!
Eine Sache noch:
Ich habe eine identische HM Schaltsteckdose remote (sehr remote), die seit ein paar Wochen nicht schaltet und nur "MISSING ACK" anzeigt. ich hab noch eine 2. FHEM Installation mit CUL, die näher am Device steht, mit der die Steckdose aber nicht gepairt ist.
Irgendeine Chance, mit diesem FHEM diese Steckdose trotzdem zu schalten?
Keine Möglichkeit, irgendwelche Knöpfe zu drücken oder ähnliches....
Äh, anderes fhem mit CUL in Reichweite aber (noch) nicht gepaired?
Es gibt folgende Möglichkeiten (u.a.):
eine vccu und den 2ten CUL per ser2net (dann fällt er aber für das fhem wo er steckt weg)...
den Aktor dort pairen und per http-Request, mqtt, R-fhem, ... dann "fernbedienen"...
vccu und dann ein per LAN/WLAN abgesetztes weiteres IO in die Nähe, z.B.: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
EDIT: evtl. keinen CUL sondern ein besseres IO (HMOD-PCB) oder bessere Antenne an den CUL...
Sofern ich vetstanden hab was du meinst...
Gruß, Joachim
Es ging eher um eine "Notfall-OP", also den CUL, mit dem die Steckdose gepairt ist, auf dem anderen FHEM zu "simuliern" oder ähnliches, um doch noch die Steckdose zu schalten. Für ein neues Pairing müsste ich ja den Knopf an der Steckdose drücke, das geht wie gesagt nicht, da remote...
Pair serial...
...vorher nat. das bestehende pairing "löschen"...
...also unpair...
Oder eben abgesetztes Funkmodul und vccu...
Gruß, Joachim
Jau, hatte ich gestern auch schon probiert, sowohl GUI als auch Kommandozeile, da passiert genau nichts, nichts im Log. Was kann man da falsch machen? :-(
PS: Pairing löschen nutzt aber nichts, wenn der bisherige CUL wohl keinen Funkkontakt (derzeit) zur Steckdose habt, oder?
Dann geht nur abgesetztes Funkmodul...
Evtl. auch temporär den anderen CUL einbinden oder dem temporär die HMID des anderen Systems vergeben, dann ein unpair senden zurück tauschen (also HMID) und dann damit pairen...
...und "fernsteuern"...
Gruß, Joachim
Uii, klingt komplex.
Einfach an dem näher gelegenen FHEM dem CUL die HMID des anderen (mit dem die Steckdose gepairt ist) vergeben und dann irgend ein Kommandozeilen Voodoo (along the line: send Steckdose [Seriennummer kenne ich, aber mit der bin ich nicht gepairt] "ON") und gut ist (also ohne pair und unpair) wird nicht gehen?
Wenn nicht gepaired, stimmt die HMID nicht und das Kommando wird abgelehnt...
Basics bzgl. Homematic...
Warum nicht zum unpair (oder Reset) den PI mit dem gepaited ist näher hin...
Danach dann mit dem fhem was näher steht ein pair serial und dann ist er damit gepaired.
Kann darüber geschalten werden, auch "remote" durch das jetzige fhem: rFhem, mqtt, http, ...
EDIT: oder (erneut/letztes Mal) ein "abgesetztes" 2tes Funkmodul und vccu...
Gruß, Joachim
Zitat von: MadMax-FHEM am 16 August 2021, 00:02:29
Wenn nicht gepaired, stimmt die HMID nicht und das Kommando wird abgelehnt...
Ich bin neu bei HM, aber die HMID wird doch von mir vergeben. Ich könnte doch dem nächstgelegenen fhem die korrekt HMID (von dem fhem mit dem pairing) konfigurieren, kann der dann mit der Steckdose quatschen?
Zitat von: MadMax-FHEM am 16 August 2021, 00:02:29
Warum nicht zum unpair (oder Reset) den PI mit dem gepaited ist näher hin...
Alles Mechanische scheidet aus. Knöpfe drücken, raspis verschieben (vermutlich wäre damit das ganze Problem sowieso gelöst) etc. ist keine Option, da die Installation remote ist. Remote wie in 1000 km weit weg und unbeaufsichtigt (von jemandem, der da was machen könnte). Ich habe die GUI von beiden fhem Installationen und jeweils ssh in die Raspis. That's it. ;-)
Es ist nicht lebensnotwendig, aber ich wollte halt mal wissen, ob man notfalls die Steckdose mit dem 2. fhem (ohne pairing) ansteuern kann durch einen Hack...
warum gibt es 2x fhem mit unterschiedlichen hmid?
Zitat von: claudio-fhem am 16 August 2021, 11:15:00
Es ist nicht lebensnotwendig, aber ich wollte halt mal wissen, ob man notfalls die Steckdose mit dem 2. fhem (ohne pairing) ansteuern kann durch einen Hack...
Wie bereits geschrieben: ohne Pairing keine Schaltbefehle...
Wenn das 2te fhem (kurzzeitig) die HMID des 1ten fhem bekommt (Attribut) und du dann ein pair serial auslöst und autocreate aktiv ist, sollte/könnte das Device auch im 2ten fhem "da sein"...
...dann ein unpair...
...setzen der "alten" HMID und ein pair serial...
...danach kannst du dann mit dem 2ten fhem und der dort vergebenen HMID steuern.
(soweit die Theorie)
Von fhem1 aus geht das dann eben auch.
Per mqtt, rFhem, http, telnet, ...
Und klar: warum überhaupt in "einer" Installation 2 HMIDs? Statt vccu und einbinden eines der beiden CUL per ser2net...
...gut verm. erst nächstes Mal...EDIT: bzw. was ist den mit den jeweiligen CULs gepaired? Nur "Dauerstromer"? Dann könnte man das ja eigentlich sogar "remote" ändern...
Gruß, Joachim
Zitat von: frank am 16 August 2021, 11:37:05
warum gibt es 2x fhem mit unterschiedlichen hmid?
Ich wollte 2 voneinander unabhängige Systeme. Redundanz war kein Ziel. Eigentlich.
Zitat von: MadMax-FHEM am 16 August 2021, 12:35:42
Wie bereits geschrieben: ohne Pairing keine Schaltbefehle...
Woher weiss die Schaltsteckdose, dass der Schaltbefehl von dem ungepairten CUL kommt, wenn die HMID identisch ist? Ich habe zu wenig HM-Wissen, um das zu verstehen.
Könnte man über die VCCU einen "remote-CUL" auf einem weiteren raspi einbeziehen, sodaß beide gleichzeitig senden?
Zitat von: claudio-fhem am 16 August 2021, 13:20:23
Ich wollte 2 voneinander unabhängige Systeme. Redundanz war kein Ziel. Eigentlich.
Woher weiss die Schaltsteckdose, dass der Schaltbefehl von dem ungepairten CUL kommt, wenn die HMID identisch ist? Ich habe zu wenig HM-Wissen, um das zu verstehen.
Könnte man über die VCCU einen "remote-CUL" auf einem weiteren raspi einbeziehen, sodaß beide gleichzeitig senden?
Also nun: unabhängig, also UNTERSCHIEDLICHE HMIDs?
ODER: 2 Systeme mit DERSELBEN HMID? -> bringt Probleme, wenn KEINE vccu definiert ist... (dann können fhem1 UND fhem2 schalten -> Probleme ;) / der Aktor prüft nur, von welcher HMID gesendet wurde [außer AES ist auch aktiv, dann wird es kompliziert])
Mit einer vccu auf EINEM der Systeme kannst du den CUL auf dem ANDEREN System z.B. per ser2net (sofern die beiden PIs verbunden sind) in fhem einbinden, dann nat. auf dem System wo er tatsächlich steckt das define löschen!
Beide sind dann mit DERSELBEN HMID (der vccu) definiert und die vccu nutzt dann je nachdem den einen oder den anderen CUL.
(Außer du definierst selbst "preferred IOs")
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Allerdings bevor du weiter machst etc. erst mal einlesen UND (v.a.) mal GANZ GENAU schildern was du hast (und warum genau so) und was du willst (gut ist in etwa klar: einen durch fhem1 nicht erreichbaren Aktor schalten)...
Wenn beide CUL jetzt schon DIESELBE HMID haben und somit alle Geräte (wenn) mit dieser "angelernt"/gepaired sind, dann sollte das mit ser2net und vccu auch remote klappen, da die Geräte ja bereits ihre Zentrale (=HMID) "kennen"...
Gruß, Joachim
Ich bin in der Experimentierphase. Wenn man nicht genau weiss, was Komponenten und Systeme können, kann man auch keine Pläne schmieden. Wenn ich gewusst hätte, wie schwierig es ist, mit einer einfachen Schaltsteckdose eine Zeitschaltuhr zu bauen, hätte ich es wohl nicht versucht...
Thema HM-Schaltsteckdose die nicht reagiert: Die hatte jemand (ich?) bei einer Installation rausgezogen und lose auf die Steckerleiste gesetzt... pfeiff... da kann der CUL nix dafür. Dieses Problem soweit gelöst.
ZitatWenn ich gewusst hätte, wie schwierig es ist, mit einer einfachen Schaltsteckdose eine Zeitschaltuhr zu bauen, hätte ich es wohl nicht versucht
Man kann Dinge aber auch lernen. Zu Beispiel ist es für Menschen extrem schwierig, auf zwei Beinen zu gehen. Wenn Neugeborene wüssten, wie schwer, würden sie es wohl gar nicht erst versuchen.
LG
pah
Ja, klar. Aber jeder Tag hat nur 24 Stunden und Hausautomatisierung soll mir das Leben leichter machen. Ich kann nicht erst Perl und Python lernen, um eine Zeitschaltuhr hinzubekommen. Mein hauseigener Techniknerd interessiert sich für andere Dinge. Der Router und die Raspis wollen auch alle Zuwendung und v.a. Zeit. Irgendwann sind die Kapazität im Elektronikbereich erschöfft. Und nebenbei soll ja auch Geld in die Bude kommen (aka "Arbeit").
Ein paar ordentliche How-To's und eine Sammlung von funktionierenden Einsteigeranwendungen wäre prima bei FHEM.
(PS: Mir graut immer, wenn ich ein paar Monate nix mit FHEM gemacht habe vor dem Gedanken, wieder fast völlig bei Null zu starten. Ich habe dann fast alles vergessen und suche meine Threads hier im Forum, wie das alles aufgesetzt wurde. Ich habe leider nicht die Zeit und Geduld, mich neben jede Installation mit einem DIN-A5 Karoheftchen zu setzen und die Installation und das Debugging mit einem spitzen Bleistift zu protokollieren... )
Zitat von: claudio-fhem am 20 August 2021, 10:37:04
Ja, klar. Aber jeder Tag hat nur 24 Stunden und Hausautomatisierung soll mir das Leben leichter machen. Ich kann nicht erst Perl und Python lernen, um eine Zeitschaltuhr hinzubekommen. Mein hauseigener Techniknerd interessiert sich für andere Dinge. Der Router und die Raspis wollen auch alle Zuwendung und v.a. Zeit. Irgendwann sind die Kapazität im Elektronikbereich erschöfft. Und nebenbei soll ja auch Geld in die Bude kommen (aka "Arbeit").
Ja das ist schon klar und bei mir auch nicht anders...
Zitat von: claudio-fhem am 20 August 2021, 10:37:04
Ein paar ordentliche How-To's und eine Sammlung von funktionierenden Einsteigeranwendungen wäre prima bei FHEM.
Wenn man rumschaut, dann gibt es da schon Einiges...
...wie geschrieben: man muss halt rumschauen und auch "lesen" wollen...
Zitat von: claudio-fhem am 20 August 2021, 10:37:04
(PS: Mir graut immer, wenn ich ein paar Monate nix mit FHEM gemacht habe vor dem Gedanken, wieder fast völlig bei Null zu starten. Ich habe dann fast alles vergessen und suche meine Threads hier im Forum, wie das alles aufgesetzt wurde. Ich habe leider nicht die Zeit und Geduld, mich neben jede Installation mit einem DIN-A5 Karoheftchen zu setzen und die Installation und das Debugging mit einem spitzen Bleistift zu protokollieren... )
Tja, genau da liegt der Fehler!
Ich protokolliere schon immer...
...und immer wenn ich dann doch mal wieder drüber schaue, wird die Doku auch "verbessert"...
Allerdings nicht mit Block und Stift, sondern (aktuell) mit dem Attribut comment direkt bei den jeweiligen Modulen/Devices.
Gut, allgemeine Dinge dann entweder in "global" oder halt in einer Textdatei (die wird aber zunehmend kleiner)...
Hilft nicht nur, wenn ich nach einiger Zeit mal wieder was "anpacke" sondern auch beim Restore im Fall der Fälle...
...der sicher irgendwann kommt.
Für eine Zeitschaltuhr evtl. mal das MSwitch-Modul ansehen.
(Leider) nicht (mehr) über fhem Update (also im fhem Repository), sondern manuell per git (oder so)...
...aber mit Unterstützung (wieder) im Forum und einfacher Klickerei (zumindest was ich so gelesen habe, nutze es nicht selbst) für diverse Schaltaufgaben...
( https://forum.fhem.de/index.php/topic,86199.msg786438.html#msg786438 )
bzw.: https://forum.fhem.de/index.php/topic,121817.msg1164134.html#msg1164134
Gruß, Joachim
ZitatEin paar ordentliche How-To's und eine Sammlung von funktionierenden Einsteigeranwendungen wäre prima bei FHEM.
Jetzt ist es aber genug >:(
Erstens gibt es diese Texte, und sie sind auch jedermann (und jederfrau) zugänglich.
Zweitens ist es reichlich dreist zu behaupten, dass man selber leider so viel Anderes zu tun habe, dass man sich nicht mit den Grundlagen befassen könne. Die FHEM-Entwickler (für Hardware und Software) sind weder "Techniknerds", noch arbeitslose "Elektroniker" oder "Programmierer". Sondern in der Regel hervorragend ausgebildete Menschen mit anstrengenden Berufen, bei denen auch "Geld in die Bude" kommen muss. Dass sie ihr Wissen dennoch unentgeltlich mit anderen teilen, muss vor diesem Hintergrund gesehen werden.
Wer das nicht kapieren will und nicht einmal notieren mag, was er selbst an Änderungen vorgenommen hat, sollte sich vielleicht einmal das Buch "The Cathedral and the Bazaar" von Eric S. Raymond ansehen. Und dann einen kommerziellen Dienstleister beauftragen.
LG
pah
ZitatIch kann nicht erst Perl und Python lernen, um eine Zeitschaltuhr hinzubekommen.
absoluter "quatsch", das stimmt ja nun überhaupt nicht.
die "einfachste" zeitschaltuhr in fhem ist ein "at".
weder perl noch python sind notwendig.
das erste von sehr vielen beispielen aus der commandref
define a1 at 17:00:00 set lamp onist zudem, finde ich, eigentlich selbsterklärend.
oder nicht?
da muss ich mir nichts notieren, das steht im klartext direkt in fhem.cfg, nachdem ich das at definiert und gespeichert habe.
da könnte ein tag auch weniger als 24 std haben.
im vorrübergehen ist ein neuer schaltzeitpunkt erstellt.
nach 2 jahten schaue ich mir einfach erstmal ein altes at an.
define a4 at *17:00:00 set lamp on # Jeden Tag
Ich würde das a4 Beispiel nehmen für eine Zeitschaltuhr!
a wiederholt sich jeden Tag und wird in der fhem.cfg gespeichert
dem frank sein Beispiel wird nur einmal ausgeführt und nicht in der fhem.cfg gespeichert, wennnoch nicht ausgeführt-> nur im statefile und ist nach ausführung weg!
Danke für die Beispiele! Ich suche etwas nach dieser Art:
Im Bereich 1-2h (random) VOR Sonnenuntergang EIN für mind. 1-3h (random) aber nicht vor 22:30 bis 23:45 (random) aus. :-)
Ich sehe noch kein Land... Notfalls ohne Sonnenuntergang, dann ändere ich die Startzeit über's Jahr von Hand immer mal wieder.
Ja, ich habe im Wiki nachgelesen und auch mehrmals auf einen Schmierzettel angefangen etwas zusammenzutragen. Das würde ich dann einfach in die Kommandozeile copy&pasten, oder? Bekomme ich dann ein "device" in der GUI? ich habe bisher nur mit "physischen" Devices rumgemacht.
Zitat von: claudio-fhem am 21 August 2021, 10:52:15
Danke für die Beispiele! Ich suche etwas nach dieser Art:
Im Bereich 1-2h (random) VOR Sonnenuntergang EIN für mind. 1-3h (random) aber nicht vor 22:30 bis 23:45 (random) aus. :-)
Ich sehe noch kein Land... Notfalls ohne Sonnenuntergang, dann ändere ich die Startzeit über's Jahr von Hand immer mal wieder.
Ja, ich habe im Wiki nachgelesen und auch mehrmals auf einen Schmierzettel angefangen etwas zusammenzutragen. Das würde ich dann einfach in die Kommandozeile copy&pasten, oder? Bekomme ich dann ein "device" in der GUI? ich habe bisher nur mit "physischen" Devices rumgemacht.
Ob du hier ein exakt passendes copy/paste Device bekommst: fraglich (außer es erbarmt sich jemand "deine" Arbeit für "dich" zu machen)...
Und ob du ein "Device" bekommst hängt halt davon ab wie du es umsetzt...
Das Beispiel mit dem at wäre dann ein Device vom Typ at ;)
Du kannst/könntest ja damit schon mal anfangen.
Dann bei at nachlesen, man kann die Schaltzeit (soweit ich weiß) auch "dynamisch" machen (z.B. mit Perl -> lernen)...
Usw.
Oder sich mal DOIF anaschauen:
https://wiki.fhem.de/wiki/DOIF
https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen
In der commandref sind auch ein Haufen Beispiele drin, vermutlich sogar eines was deinem Wunsch (sehr) nahe kommt...
...nutzen, verstehen abändern und wenn es nicht klappt: fragen (im passenden Unterforum / Damian hilft immer prompt)
Aber (etwas) Eigenleistung "darf" schon sein!
Weil: schließlich musst ja DU verstehen wie etwas geht, für den Fall, dass du etwas anpassen willst/musst oder etwas nicht (mehr) geht wie gewünscht/gedacht...
(weil ständig hoffen, dass sich immer wieder jemand "erbarmt" DEINE Sachen für DICH anzupassen ist mit Risiko behaftet / weil wie schon geschrieben: wir machen das auch "nebenbei" wir verdienen auch unser Geld anderweitig und wir bekommen "Hierfür" KEINEN Cent! Worum es auch gar nicht geht, also "wedeln mit Geld" wird HIER nicht helfen -> Profi aufsuchen, gibt es ja auch, also Leute die gegen Geld genau machen was du willst/wie du willst...)
Und eben (noch mal) der Hinweis auf MSwitch, damit sollte sich eine "Zeitschaltuhr" einfach umsetzen lassen (noch mal: "hörensagen" ich nutze das nicht)...
Gruß, Joachim
Zitat von: claudio-fhem am 21 August 2021, 10:52:15
Danke für die Beispiele! Ich suche etwas nach dieser Art:
Im Bereich 1-2h (random) VOR Sonnenuntergang EIN für mind. 1-3h (random) aber nicht vor 22:30 bis 23:45 (random) aus. :-)
Ich sehe noch kein Land... Notfalls ohne Sonnenuntergang, dann ändere ich die Startzeit über's Jahr von Hand immer mal wieder.
Ja, ich habe im Wiki nachgelesen und auch mehrmals auf einen Schmierzettel angefangen etwas zusammenzutragen. Das würde ich dann einfach in die Kommandozeile copy&pasten, oder? Bekomme ich dann ein "device" in der GUI? ich habe bisher nur mit "physischen" Devices rumgemacht.
Du solltest mAn. für solche Fragen dann einen neuen Thread aufmachen, das hat nun mit Homematic nichts mehr zu tun.
Ansonsten kann ich das Gemaule über die Doku auch nicht nachvollziehen. Zu den Basics zu Zeitschaltuhren findet man sowohl im angegrauten Einsteiger-pdf was, und wenn man mal die commandref nach "Timer" durchsucht, findet man u.A. auch die Module Timer, Weekday- und RandomTimer oder DOIF; auch für sunrise müßte es Treffer geben, usw., usf..
Hier scheint mir das Problem eher zu sein, dass du gleich "alles auf einmal" haben willst, aber nicht bereit bist, dich mit den Grundlagen zu beschäftigen - so wird das nichts!
oweia...