Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

Warum MAX_CREDIT 900?

Begonnen von Michael N., 04 Januar 2013, 12:43:57

Vorheriges Thema - Nächstes Thema

Matthias Gehre

Es scheint, dass die Ack's von uns an die Fensterkontakte nicht ankommen. Daher sendet der Fensterkontakt jeweils 5 mal,
und wir senden jedes mal ein Ack. Daher sind nach einem Fensteröffnen schon 5 Sekunden Sendezeit weg. Und da MAX_CREDIT auf
900 steht, haben wir eh nur 9 Sekunden Sendezeit.

Das Ack-Problem kann man wahrscheinlich lösen, indem man diese direkt in culfw generiert. (Das ist nämlich wahrscheinlich ein Timingproblem).
Und ich vermute, dass die Acks auch gar kein 1 Sekunden Präambel brauchen, wenn das Timing stimmt.

Als Workaround nehme ich erstmal das Ack'en von Fensterkontaktmeldungen raus, bis ich das in culfw implementiert habe.

Unabhänig davon würde ich gern MAX_CREDIT auf 3600 setzen, oder gibt es dazu noch Einwände?

Michael N.

Über die 1 Sekunden Präambel habe ich auch schon mal nachgedacht. Der Kommentar im Source verweist ja auf eine allgemeine (nicht MAX spezifische) Seite bei TI. Kann man die Präambel beim Cube beobachten? Vor allem, wie verhält er sich, wenn mehrer Kommandos innerhalb einer bestimmten Zeit gesendet werden. Man sollte doch annehmen, dass die Empfänger nach einem Aufwecken für eine bestimmte Zeit wach bleiben. Also müsste die 1 Sekunden Präambel eigentlich nur gesendet werden, wenn für eine bestimmte Zeit nichts gesendet wurde. Noch weiter gedacht würde auch das Empfangen eines Pakets die 1 Sekunden Präambel für eine bestimmte Zeit unnötig machen, da ja dann der andere Sender schon alle Empfänger aufgeweckt hat.

Ich habe mal mit meinen 3 gekoppelten Heizkörpern experimentiert. Wenn ich einen verstellte, ändert sich auch die Solltemperatur bei den anderen und es liegt definitiv keine Sekunde dazwischen.

tostmann

Gerade bei einem ACK sollte man davon ausgehen können, dass die Gegenseite noch wach ist. Es ist eher das Problem, dass durch die 1 Sekunde der Sender denkt es gäbe kein ACK mehr und das Paket erneut sendet...

Matthias Gehre

1. Der Cube erlaubt es, 33 Pakete pro Stunde zu senden. (Er exportiert über sein LAN-Interface einen dutycycle.
Bei jedem Paket geht der um 3 hoch und bei 100 ist Schluss).
Das legt also Nahe, dass ein Paket ca. 1 Sekunde dauert.

2. Außerdem hat jemand von einem Thermostat die CC1101 Konfiguration ausgelesen,
und diese ist so, dass das Thermostat jede Sekunde für ein paar Millisekunden aufwacht
und und nach dem Präambel checkt. (Genau wie in dem Paper von TI, auf das im Source verwiesen wird)
Da der Zeitpunkt des Aufwachens unbekannt ist, müssen wir eine ganze Sekunde senden,
um den Zeitpunkt auf jeden Fall zu erwischen.

Du kannst damit gerne etwas experimentieren, aber bei meinen Experimenten hat ein Präambel unter einer Sekunden
immer wieder zu "Missing Ack" von der Gegenstelle geführt.

Matthias Gehre

Ich dachte, dass FHEM zu langsam ist, um das Ack schnell genug nach dem Empfangen der ShutterContactState zu versenden.
Vielleicht liegt es auch am langen Präambel.

Wie schon oben geschrieben, hab ich vor Acks mit kurzem Präambel zu testen.



Michael N.

Zitat von: Matthias Gehre schrieb am Fr, 11 Januar 2013 13:362. Außerdem hat jemand von einem Thermostat die CC1101 Konfiguration ausgelesen,
und diese ist so, dass das Thermostat jede Sekunde für ein paar Millisekunden aufwacht
und und nach dem Präambel checkt. (Genau wie in dem Paper von TI, auf das im Source verwiesen wird)
Da der Zeitpunkt des Aufwachens unbekannt ist, müssen wir eine ganze Sekunde senden,
um den Zeitpunkt auf jeden Fall zu erwischen.

Klar brauche ich erst mal eine Präambel von 1 Sekunde, aber wenn der Receiver wach ist, geht er dann sofort nach dem Empfang eines Pakets wieder in den Sleep Modus oder bleibt er noch ein bisschen wach für den Fall, dass "gleich" noch ein weiteres Pakte kommt? Laut http://www.mikrocontroller.net/topic/244432#2824930 steht MCSM1.RXOFF_MODE auf IDLE. Der weitere Verlauf nach dem Empfang hängt also von der MCU ab. "Lauscht" sie noch ein wenig (versetzt den CC1101 also noch mal in der RX mode) oder geht sie gleich wieder in den SLEEP mode ("When the MCU has read the packet, it can put the chip back into SLEEP ..."). Dass MCSM1.RXOFF_MODE auf "IDLE" steht spricht natürlich gegen ein weiteres Lauschen (sonst hätte der Entwickler es besser auf "Stay in RX" gestellt), bedeutet es aber nicht zwingend.

Matthias Gehre

Und eine andere Sache:
clock_hsec wird im Timer interrupt hochgezählt bis 124, dann overflow.
D.h. clock_hsec=0 sollte genau einmal pro Sekunde auftreten.

In Minute_Task() wird dann credit_10ms inkrementiert wenn clock_hsec = 0 ist.

Nun kann es aber passieren, dass Minute_Task() ein "clock_hsec=0" verpasst, weil irgendeine
der Funktionen vorher zu lange brauchte (z.B. das Versenden einen MAX Pakets braucht schon mehr als eine Sekunde).

So steigt credit_10ms also langsamer als um 1 pro Sekunden.
Wäre es da nicht besser, credit_10ms direkt in der Timer ISR hochzuzählen?

Matthias Gehre

Klar, es kann auch anders sein. Ich habe nur Indizien angeführt. Allerdings habe ich nicht genug Zeit, um das ausführlich zu testen.

M.E. ist
http://www.mikrocontroller.net/topic/244432#2824930
nicht die Konfiguration eines CC1101 in einem MAX-Device, sondern die CC1101 Konfiguration
von unserem CUL (möglicherweise auch von Cube).

Für die Config von einem Max-Device, siehe
http://www.fhemwiki.de/wiki/MAX
Dessen Quelle ist
https://groups.google.com/d/msg/cul-fans/16nnlz38Zws/6AeZyDsOc7UJ
(in dem Thread gings um das gleiche wie hier)

Tobias

Nachtrag: ich habe mal einen nagelneuen (heute von ELV geliefert) FK angelernt. Sobald er gepaired wurde sendet er bei Zustandsänderung immer 5x (wohl wegen dem angesprochenen ausbleibenden Ack), blinkt 3x (laut Manual wurde das Sendepaket vom Empfänger nicht empfangen) und in fhem steht dann "open (rf error)" bzw. "closed (rf error)"
Mehr kann glaube ich, hier nicht beitragen :(
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Matthias Gehre

Hey,

mir ist es gelungen, das Ack für die ShutterContactState richtig zu senden.
Das passiert jetzt direkt in der culfw, und zwar immer dann, wenn an eine vorher konfigurierte
Addresse (Neuer Befehl "Za", z.B. Za123456" eine ShutterContactState Nachricht empfangen wird.
Und das Ack muss wie schon vermutet ohne das 1 Sekunden Präambel gesendet werden.

culfw und FHEM Änderungen sind committed.

Bitte testen!

Michael N.

Was spricht dagegen, das ACK vom CUL für alle Meldungen automatisch (und ohne Präambel) senden zu lassen?

Matthias Gehre

Weil das Protokoll nur ein Ack auf ShutterStateContact Nachrichten vorsieht,
und nur wenn sie an den angelernten Cube (was wir mit dem CUL emulieren) gesendet werden.
Außerdem wollen wir ja nicht unseren Nachbarn mit Acks auf dessen Fensterkontakte stören.

Michael N.

Oh, habe ich das völlig missverstanden? Wenn der CUL etwas an ein Heizkörperthermostat sendet, erwartet er doch auch ein ACK. Und wenn ein Heizkörperthermostat eine Themperaturänderung an ein assoziiertes Thermostat sendet, erwartet es auch ein ACK (sonst fängt das Antennensymbol an zu blinken, habe ich schon mal gehabt). Aber alle anderen Meldungen eines Thermostats über Änderung der eingestellten Temperatur, Ventilstellung etc. sind nur "Infos", die vom Cube/CUL nicht bestätigt werden müssen?

Matthias Gehre


Michael N.

Könnte der CUL dann nicht doch auf jeden ShutterStateContact mit ACK antworten, denn an unsern CUL senden doch nur die angelernten (also unsere und nicht der vom Nachbarn)? Also könnte der CUL doch jedes an ihn gesendetes Paket vom Typ ShutterStateContact ACKnowledgen.

Ich habe keinen Fensterkontakt, aber die aktuelle Lösung würde nicht funktionieren, wenn jemand mehrere hat, oder?