Guten Morgen.
Ich bin etwas am Verzweifeln.
Gestern sind meine 868er Thermostate als Bausatz gekommen, wurden erfolgreich zusammengebaut/Montiert und mit Fhem verwurstet.
Das grundsätzliche steuern/programmieren der Regler über FHEM funktioniert auch.
Nun wollte ich diese mit den jeweiligen Fenstersensor, die sind schon seit einer Woche in FHEM und melden auch artig den Status, verknüpfen.
Das Vorgehen ist ausgiebig beschrieben in der Wiki und andern Blogs.
Ich hab auch den Taster des Sensors nach
set Fenster_bad 0 Heizung_Dad_WindowRec single
gedrückt. Die LED blinkte kurz (ACK?) grün und war danach aus.
In der Peerlist des Reglers steht auch der Name des Sensors.
Danach wurden die Infos unter HMinfo:
configCheck done:
missing register list
Fenster_Amy: RegL_00.,RegL_01.
Fenster_Bad: RegL_00.,RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: Fenster_Amy:
peer not verified. Check that peer is set on both sides
Heizung_Amy_WindowRec p:Fenster_Amy
Heizung_Bad_WindowRec p:Fenster_Bad
protoEvents done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
Fenster_Amy : done_Errors:1 | - | 4: | 3: # 7 | 1: | - | -
Fenster_Bad : pending | 4 pending| 9: | 6: # 4 | 1: | - | -
Heizung_Amy : - | - | - | - # - | - | - | -
Heizung_Bad : done | - | 6: | - # - | - | - | -
================================================================================================================
sum 1 |4 |19 |9 #11 |2 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : none
status request :
autoReadReg wakeup :
status request wakeup:
autoReadTest : Fenster_Bad Heizung_Bad_WindowRec
IODevs:CUL_IO1:Initialized condition:-
Wartet man steht der Bad Sensor auch auf done_Errors:1
Weiteres rumprobieren verschlimmert die Situation nur wegen der pending cmds
Was mache ich falsch?
Hi,
Du musst die Meldungen aus configCheck einfach abarbeiten.
Zuerst die Infos von den Fensterkontakten holen. getConfig und immer wieder und mit viel Ruhe die Daten übertragen -> Configtaste drücken und nicht den Sensor auslösen!
Du hast einen CUL und keinen richtigen HM IO? Das macht die Sache nicht besser.
Gruß Otto
Hallo Otto,
Stehe gerade genau seit gestern vor dem selben Problem. Optischer Fenstersensor + Heizkörper Thermostat zusammengebaut aus ELV Bausatz. Wenn es nicht sonst überall gehen würde ... Nur die neuste Kombi im WC versteht sich nicht. Hast Du noch eine geniale Idee? Ablernen und erst Sensor+Thermostat peeren und danach an Fhem anlernen? Bin ratlos. Gestern ein - zwei mal kurz hat das Thermostat auf das geöffnete Fenster sofort reagiert und dann nicht mehr.
Hallo det.
nein leider nicht. Ich habe die Thermostate gar nicht (nur ein paar Wand Thermo als Sensoren) und die Fenstersensoren nur als Melder. Hab zwar gestern mal die Kopplung probiert, die lief ohne Problem. Praktische Alltagserfahrung damit habe ich nicht.
Gruß Otto
Hallo Otto.
Ich hab ein GetConfig auf alle Geräte gemacht. (es sind ja nur 4 Stk)
Die Thermostate waren nach ca. 2 min fertig, aber die Fenster Sensoren stehen seit Stunden jeweils auf "3 pending".
Eine Frage am Rande:
Kann man an den ,,Wether" Kanal auch die Temperatur eines ESPEasy .DHT22:Temperature verknüpfen? davon hab ich genug in der Bude verteilt.
Zitat von: Basti-K am 25 Oktober 2018, 11:11:41
Hallo Otto.
Ich hab ein GetConfig auf alle Geräte gemacht. (es sind ja nur 4 Stk)
Die Thermostate waren nach ca. 2 min fertig, aber die Fenster Sensoren stehen seit Stunden jeweils auf "3 pending".
Wie hier schon beschrieben wurde: nach dem getConfig bei dem Sensor auf den Peering/Pairing Knopf drücken. Die gesamte Prozedur muss auch ggfs. mehrfach wiederholt werden. Und immer nur für ein Device getConfig ausführen und warten bis das erfolgreich war.
Zitat von: Basti-K am 25 Oktober 2018, 11:11:41
Eine Frage am Rande:
Kann man an den ,,Wether" Kanal auch die Temperatur eines ESPEasy .DHT22:Temperature verknüpfen? davon hab ich genug in der Bude verteilt.
Ja, ist im Wiki beschrieben: https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren
(in der VCCU das attribute cyclicMsgOffset auf z.B. 250 setzen - sonst gibt es Aussetzer und das Thermostat schaltet wieder auf die interne Temperaturmessung um)
Ja, mit der gebotenen Ruhe und nach mehreren Versuchen geht es dann wirklich auf einmal.
OK, das GetConfig bedarf eines Drucks des Tasters auf den Sensor, dann werden die CMDs abgearbeitet aber, das peern in die andere Richtung will einfach nicht.
Dies ist die Situation nachdem ich fehm neu gestartet hatte.
Zuerst waren es nur je ein cmd am Fenster und am Thermostat.
Das cmd an der Heizung verschwindet mit done. Drück ich den Taster am Sensor sind es auf einmal 4 CMDs.
Diese werden aber dann nicht mehr Abgearbeitet.
protoEvents done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
Fenster_Amy : pending | 4 pending| 30: | 13: # 17 | 3: | - | -
Fenster_Bad : done | - | 20: | 9: # 21 | 3: | - | -
Heizung_Amy : done | - | 44: | - # - | - | - | -
Heizung_Bad : done | - | 84: | 1: # - | - | - | -
================================================================================================================
sum 0 |4 |178 |23 #38 |6 |0 |0
wie lange muss man den drucken? 5 Sekunden lang macht ein Reset.
Das Verhalten nach dem drücken ist auch eigenartig.
Beim ersten Versuch quittiert die LED mit einen grünen blink.
Beim zweiten blinkt die LED 3x gelb dann 1x Grün.
Dann kommt aber MISSING ACK
Noch ein Versuch, 15x nur gelb und auch nur noch MISSING ACK
Dann hilft nur noch Akku raus rein.
Geduld bei dem Thema ist schön und gut, aber das Kind fühlt sich langsam genervt weil ich ständig in ihr Zimmer laufe zum Taster drücken und die Dame des Hauses unterstellt mit schon blasenschwäche weil ich so oft ins Bad renne.
Ich probiere das nun schon seit 3 Tagen.
Gibt es zur Not ein Workaround über einen virtuellen Sensor?
Zitatwie lange muss man den drucken? 5 Sekunden lang macht ein Reset.
Für die Datenübertragung nur kurz. 5 Sekunden macht meines Wissens nur die Vorbereitung für den Reset, ich glaube danach muss man nochmal 5 sec drücken. Das steht aber genau im Handbuch.
Wenn Du wirklich reset gemacht hast, brauchst Du Dich über missing ack nicht wundern. Da musst Du dann erstmal neu pairen.
Nochmal die Frage: Du hast einen CUL? Wenn ja: mit der Time Stamp Firmware? Mit einem CUL mit Standard Firmware brauchst Du nicht weiter versuchen...
Gruß Otto
Hallo Otto.
Ja das mit den 5 Sekunden hab ich hier auch schon gelesen.
Heute morgen hab ich es noch mal durch das Löschen des ganzes Geräts und dann durch ein Reset Probiert. Dann blinkt die LED auch rot nicht orange wie ich es vorher hatte. Dann war es auch klar dass ich neu Pairn musste.
ja ich hab einen Nano CUL den habe ich vorgeflasht gekauft weil ich schnell ans Ziel wollte.
V 1.67. nanoCUL868
Naja wie schon gesagt: Du wirst damit nicht glücklich werden. Die Fenstersensoren sind zwar nicht kompliziert aber sensibel - sogar wenn man einen Homematic IO hat.
Zum Einlesen
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Edit:
ZitatDann blinkt die LED auch rot ...
Wenn du einen wirklichen Reset gemacht hast, dann darf nichts rot blinken, außer beim Power on.
Wenn der Sensor nicht an einer Zentrale angelernt (gepairt) ist und nicht gepeert ist, meldet er bei Betätigung des Sensors grün. Wenn Du die Configtaste kurz drückst und ihn nicht anlernst, blinkt er ruhig für eine paar Sekunden (10 oder 20?) orange.
Also Mein Workaround wird theoretisch akzeptiert vom Thermostat.
die Beiden Gerte sind vollständig gepeert.
Aber ich bekomme das Kommando nicht auf die Reihe wie ich den State vom Fenster Sensor auf den des virtuelles Sensors kopiere.
Könnte mir da jemand helfen?
define Fenster_Bad_v CUL_HM AABBCA
set Fenster_Bad_v virtual 1
define at_Fenster_Bad_v at +*00:02 { my $F=(ReadingsVal("Fenster_Bad","state",0));; fhem "set Fenster_Bad_v_Btn1 STATE $F" }
Zitat von: Basti-K am 26 Oktober 2018, 09:17:43
Ich probiere das nun schon seit 3 Tagen.
Nicht aufgeben, es geht. Hilfreich bei Bewegungsschwäche ist ein Laptop oder ein Tablet.
Wie Otto schon gesagt hat, der Fenstersensor ist etwas eigenwillig. Man muß meistens mehrmals kurz drücken, um eine längere Befehls-Queue vollständig abzuarbeiten. Also, Befehl absetzen - am Sensor kurz drücken, Geblinker abwarten, wieder kurz drücken, warten usw. Wenn er dann anfängt, langsam zu blinken, ist er meist durch. Zwischendurch immer wieder im FHEM nachsehen, ob noch was pending ist.
Wenn man dann hektisch weitere Getconfigs absendet oder das Peering wiederholt, besteht auch schnell die Gefahr des Overloads beim IO, dann geht erstmal gar nichts mehr. Sollte man immer bei solchen Aktionen im Auge behalten.
Gruß
G.
Tag 5:
Ich habe alle HM Geräte zurück gesetzt.
Und aus Fehm gelöscht.
Es wurde erst mal nur ein Set gepiart, gewartet, einzeln getConfig, gewartet alles sauer abgearbeitet.
Keine cmds mehr in der Warteschlange.
Danach wie so oft:
set Fenster_Amy peerChan 0 Heizung_Amy_WindowRec single
Taste an Sensor gedruckt, ein CMD wird vom Fenster Sensor verarbeitet 4 werden ignoriert. Wie immer.
Immerhin habe ich jetzt verstanden was schnell und langsam blinken bedeutet.
Schnell Verarbeitung (ein blink pro CMD) langsam es wird nur probiert.
configCheck done:
missing register list
Fenster_Amy: RegL_00.,RegL_01.
Register changes pending
Fenster_Amy
peer not verified. Check that peer is set on both sides
Heizung_Amy_WindowRec p:Fenster_Amy
PairedTo mismatch to IODev
Fenster_Amy paired:0x000000 IO attr: AABBCC.
Die obere Meldung war vor dem peerversuch nicht da.
Das mismatch ist mir schleierhaft warum.
Ich bin langsam echt ratlos.
ZitatFenster_Amy paired:0x000000 IO attr: AABBCC.
Bedeutet der ist noch nicht mal fertig gepairt! Bevor das nicht sauber ist, braucht man etwas anderes (peeren) nicht versuchen.
Du bist, wie immer ;), zu schnell :-X
Auf Grund des CUl mit Original Firmware werden Pakete nicht sauber verarbeitet und verworfen. Das bedeutet: nur wenn Du großes Glück hast kommen die notwendigen Informationen beim x-ten Versuch auch wirklich an.
Pairen kann man immer wiederholen
OHNE Reset oder löschen zwischendurch!!!
"mismatch" => der fk ist halt noch nicht gepairt.
das löschen der devices in fhem und das resetten der devices ist vollkommen überflüssig. was soll das bringen?
statt immer wieder bei NULL anzufangen, hättest du mal den cul neu flashen sollen.
ich schreib es trotzdem, obwohl otto schneller war. :)
Und welche ist die richtige? Von 1.67 auf 1.67 brachte irgendwie keine Änderung.
Zitat von: Basti-K am 27 Oktober 2018, 20:20:19
Und welche ist die richtige? Von 1.67 auf 1.67 brachte irgendwie keine Änderung.
Diese hier: https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466
Hatte auch Probleme mit dem CUL.
Mit dieser FW dann nicht mehr.
Allerdings bin ich dann letztendlich auf ein original HM-Funkmodul umgestiegen...
Gruß, Joachim
Joachim sein Link ist eine Stufe weiter, aber in Antwort #10 stand der Link ins Wiki und von da aus geht es weiter.
Da es immer wieder neue Entwicklungen gibt, habe ich versucht im Wiki einen Punkt zu verlinken von dem aus es möglichst stabil weiter geht ;)
Gruß Otto
Hallo zusammen.
Erst mal danke für Eure Zeit, aber ich komme einfach nicht weiter bzw. werde immer verwirrter.
Mein Vorgehen um mein Produktiv FHEM nicht zu stören und um sicher nah genug am Problem zu sein:
Fhem auf den Notebook (Linux) die Fhem config dort importiert.
Ich habe den Nano mit ,,TSnanoCUL.hex" geflascht.
Die Fies unter /FHEM übernommen.
Das Gerät also der CUL hat den Status initialisiert.
Mir fällt sofort auf, dass auf einmal ganz viele hm Geräte discovert wurden. Das sind dann wohl welche aus der Nachbarschaft bei >-100db
Meine VCCU schickt laut monitor cmds zu einigen Geräten? Ob das so richtig ist?
Wie auch immer, ich habe versucht ein Paar Geräte neu zu pairn, aber das bleibt erfolglos. Das sieht man beim thermostat ganz gut.
Benötigt man für ein TSCUL eine andere Konfiguration, weicht das Handling von den How2s bezüglich eines ,,Standard" NanoCUL ab?
Es bleibt alles (Vorgehen) wie für CUL bzw. HM generell beschrieben.
Das Define muss von CUL auf TSCUL (sollte beschrieben sein) geändert werden.
vccu tauscht Daten aus ist das ok?
Lässt sich ohne genauere Angaben nicht beantworten...
Da eine vccu vorhanden kannst du darüber die "unerwünschten" Geräte ignorieren lassen...
Ansonsten ein list von vccu, TSCUL und Geräten zu denen du Fragen hast/unsicher bist...
EDIT: und überschriebene Module (sollten mittlerweile ja nicht mehr viele sein) vom Update ausschließen, sonst bekommst du beim nächsten fhem Update die "Originale" wieder drüber... Und nach dem Kopieren die Rechte anpassen/prüfen nicht vergessen (wobei scheint ja zu passen sonst wären ja verm. Fehler gekommen)...
Kurz da nur Handy grad...
Gruß, Joachim
Heureka, mit den Hinweisen habe ich es hinbekommen.
Nun läuft es wie erwartet.
Als FHEM Noob sieht man leider den Wald vor lauter Bäumen nicht.