FHT8V reagiert nur einmal nach dem Pairing

[allgaier]

Servus,
Ich habe dasselbe Problem dass hier beschrieben wird:
https://groups.google.com/forum/#!topic/fhem-users/IwszHe3WjUU
Leider wurde das Problem damals scheinbar nicht gelöst.

Als Hauscode hab ich beim Cuno (VERSION V 1.52 CUNO868) und beim Fht8v die 2000 verwendet.
- Den fht8v gepaart. Erstes Signal wird bestätigt. Und der Motor dreht auf den gegebenen Wert.
- Alle 115sec blinkt das Antennensymbol auf dem fht8v
- set Stellantrieb valve 10 kommt aber erst "Stunden" später oder gar nicht?!? an.

Weiß jemand eine Lösung für mein Problem?

Gruß

[rudolfkoenig]

Die wahrscheinlichste Ursache ist, dass der CUNO die 115+x Sekunden nicht genau einhaelt, und das ist wichtig, weil die FHT8v's nur fuer eine Sekunde wach bleiben. Hypothese: die Zeit-Zaehlung laeuft auf dem CUNO aus dem Ruder, weil diverses (IR/Ethernet/OneWire/etc) gepollt wird.

[allgaier]

Servus, danke für die schnelle Rückmeldung!
Und wie reisse ich das Ruder wieder rum?

Gruß

[rudolfkoenig]

Debuggen und Code fixen.

[allgaier]

Servus,
Leider weiß ich damit nicht wo ich den Fehler suchen und beheben soll.

Heißt das der cuno ist so beschäftigt, dass "seine eigene uhr" zu langsam läuft?

Wie kann ich nachsehen, welche Prozesse auf dem cuno laufen? Mit den schlüsselbefehlen wie set cono raw x11 bin ich auch nicht weitergekommen.
Gibts da ne doku?

Gruß

[rudolfkoenig]

Wie kann ich nachsehen, welche Prozesse auf dem cuno laufen?

Nachsehen? Debug Meldungen einbauen. Prozesse? Es gibt nur Funktionen, die in einer Endlosschleife aufgerufen werden.
Bitte nicht vergessen: culfw ist fuer ein MCU entstanden, was 8kb freien Programmspeicher und 512Bytes RAM hat, in diesem Speicher werden mehrere Protokolle in Software dekodiert. Da war kein Platz fuer Luxus wie Prozesse/ps/etc.
Bisher hat sich keiner die Muehe gemacht, das etwas groessere MCU der CUNO voll auszunutzen, aber die Quellen sind ja frei.


Btw.: Benutzerdoku fuer culfw gibts hier: http://culfw.de/commandref.html

[allgaier]

Servus,
so nun habe ich mal die neue culfw (1.61) geflasht und siehe da, jetzt geht der FHT8v wie gewünscht und stellt die werte nach 2min richtig ein.

Leider geht der IR empfang nicht mehr. Lt. der board.h in Devices\CUNO2 sollte IR eingeschaltet sein, wenn ich es richtig verstehe.

Wie kann ich prüfen, woran es lag? Muss ich es irgendwie noch aktivieren? in der commandref und im Forum kann ich leider dazu nichts finden.

(vorher habe ich die culfw von hier geflasht: https://forum.fhem.de/index.php/topic,10541.msg60072.html#msg60072 da ging IR)

[rudolfkoenig]

Code Auswählen Erweitern

Leider geht der IR empfang nicht mehr. Lt. der board.h in Devices\CUNO2 sollte IR eingeschaltet sein, wenn ich es richtig verstehe.
Nope, da steht: #undef  HAS_IRRX, laut "svn blame/svn log" wurde es vor drei Jahren auskonfiguriert, mit dem Kommentar:

removed IR support - not compiled it by default anymore

Ich meine mich daran zu erinnern, dass damals FHT bzw. die zu starke Bremswirkung der IR-Bibliothek als Ursache genannt wurde. Bei einer Interrupt-Rate von 16kHz kann halt der 8MHz Prozessor nicht so viele Sachen parallel erledigen.

vorher habe ich die culfw von hier geflash

Dann muss man aber auch da fragen.

[allgaier]

Servus,
oh, dann habe ich das Falsch interpretiert.

Somit wird es aber auch keinen Sinn machen, das HAS_IRRX zu aktivieren wenn es damit probleme gibt. Das war der eigentliche grund, warum ich den CUNO gekauft habe. Schade!

Wie würde denn sonst Sinn machen einen IR Empflänger an FHEM anzuschließen?

Meine ganze Technik steht eigenltich in unserer Speiss, nur der CUNO ist über LAN Kabel im Wohnzimmer mit dem Raspberry verbunden.
Nun könnte ich den CUNO auch in die Speiss packen und einen zusätzlichen Raspi im Wohnzimmer mit einem IR Sensor laufen lassen. Das ganze dann mit FHEM2FHEM verbinden.
Macht das Sinn, oder bekomme ich es einfacher hin meine FHT80b´s und einzelne FHT8v und zusätzlich die bedienung über IR zu ermöglichen?
An Hardware ist derzeit ein Raspberry, CUNO und ein RFXTRX vorhanden.

Gruß Markus

[rudolfkoenig]

Sorry, zu IR kann ich nichts sagen. Eigentlich auch zu CUNO nicht, nie eins gesehen

[allgaier]

Hat jemand anders evtl. Erfahrung mit dem cuno und fht8v und ir ?

Gruß

[tschirch]

Hallo, kann leider bei CUNO und IR nicht helfen. Ich hatte nur das gleiche Problem, dass nach dem Pairing der FHT8V nur einmal reagierte. Deshalb bin ich der Meinung, dass mein Beitrag hier am Besten her passt.

Ich habe jedoch einen CUL-SCC von BUSWARE. Nachdem ich viel gelesen und probiert hatte, habe ich festgestellt, dass der CUL trotz neuester Firmware 1.66 mit dem Senden stets ein bisschen zu spät kam. Die LED zum Senden ging an, nachdem das Antennensymbol des FHT8V wieder an war. Ich musste also die Zeit zum erneuten Senden verkürzen. In der Datei fht.c Zeile 404 habe ich dann eine halbe Sekunde weniger in der Berechnung angesetzt: (125*(230-fht_hc1&(0x7))) habe ich geändert in (125*(229-fht_hc1&(0x7)))

Damit konnte im SCC die richtige Zeit erzeugt werden. Warum das im SCC so gemacht werden muss gegenüber den anderen CUL-Hardware-Formen, kann ich nicht beantworten. Aber vielleicht ist das ein Hinweis für die Entwickler der CUL-Firmware.

Übrigens eine großartige Leistung von R. König und Co.! Ich bin von FHEM total begeistert! Auch wenn es manchmal nicht so will wie man erwartet.

MfG Steffen

[rudolfkoenig]

Die Formel lautet vollstaendig:

(125*(230+fht_hc1&(0x7)))>>1

also + statt - und das Teilen durch 2 fehlte auch.
125 ist die Frequenz des culfw Timers, und die FHTs wachen jeweils nach (115+0.5*(letzten 3 Bits der Housecode)) Sekunden auf.
Wenn der u.g. Formel beim SCC funktioniert, dann ist moeglicherweise der Quarz falsch. Damit sollten auch anderswo Probleme auftreten. Testen kann man diese Theorie mit

Code Auswählen Erweitern

{ fhem "get CUL uptime;; sleep 60;; get CUL uptime" }
in der Eingabezeile, und nach eine Minute das FHEM-Log pruefen.

[tschirch]

Hallo, da ist doch glatt aus plus minus geworden. Sorry, mir ging es einfach nur um die 230. Mit dem >> konnte ich nichts anfangen. Ich programmiere selber nicht (mehr) und hatte es bis jetzt auch noch nicht mit C zu tun. Habe jetzt verstanden, dass das ein Shift um 1 Bit nach rechts ist.

Und ja mit dieser Formel funktioniert es seit gestern tadellos. Vorher, wie gesagt, nicht.

Ich habe deine Idee mit dem Befehl umgesetzt: erste Ausgabe 23:20:44 und im Logfile eine Minute später 23:21:44
Also genau eine Minute Differenz! Ich weiß leider zu wenig über den Prozessor und ob ihr Interrupts für die zeitliche Steuerung nutzt, deshalb kann ich leider nicht weiterhelfen.
Wenn du weitere Ideen hast, was ich ausprobieren kann, dann natürlich gerne.

Viele Grüße
Steffen

[rudolfkoenig]

Nach etwas nachdenken: Mit deiner Aenderung werden die Daten 1/230s eher gesendet, als ueblich. Wenn das funktioniert, dann ist der Quartz etwa (1+1/230) mal so schnell, als vom firmware erwartet. Um das zu messen, sollte der Abstand zwischen den zwei Abfragen deutlich mehr als 230 Sekunden betragen, z.Bsp.
{ fhem "get CUL uptime;; sleep 1200;; get CUL uptime" }

[tschirch]

Hallo, die Zeit zu verlängern, war die richtige Idee. Bei 5:45:08 gestartet und bei 6:05:04 beendet. Die "Uhr" im CUL läuft tatsächlich zu langsam! Auf 20min fehlen 4s! Deshalb kam das Senden auch immer zu spät.

Was sagt uns das jetzt?

Gruß
Steffen

[rudolfkoenig]

Wenn dein SCC in 20 Minuten nur bis 19:56 gezaehlt hat, dann ist die MCU etwa 0.33% zu langsam. Deine Loesung (230->229) beschleunigt sie um 0.43%, muesste also wieder in etwa passen. Mir sind keine anderen Protokolle bekannt, die eine so lange Zeitspanne benoetigen, deswegen muesste mit deinem Fix das Problem geloest sein.

P.S.: mein CUL hat in ca 12 Stunden eine Sekunde Abweichung gezeigt, was aber auch dem Rundungsfehler geschuldet sein kann.

[tschirch]

Hallo, habe versucht bei BUSWARE etwas Hilfe und Unterstützung zu bekommen. Da bin ich leider abgeblitzt. Sie fühlen sich für alles, was mit der Firmware zu tun hat, natürlich nicht verantwortlich. Da habe ich eigentlich mehr erwartet, weil es ja auch ein Hardwarefehler sein könnte.

Ich denke mehr Aufwand hineinstecken lohnt sich nicht. Vielleicht checke ich nochmal etwas genauer die Zeiten, aber das war es dann auch schon. Nochmal vielen dank für die Hilfe und Unterstützung.

Viele Grüße
Steffen