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

Michael N.

Hallo,

ich bekomme beim abendlichen Umstellen aller meiner MAX-Heizkörperthermostate einen "LOVF". Nun habe ich mal nachgerechnet und festgestellt, dass ich eigentlich deutlich unter der 1% Grenze bleiben müsste. Also habe ich mal im Source-Code nachgesehen und gefunden, dass in Wirklichkeit eine 0,25% Grenze implementiert ist, da der credit_10ms nie wirklich auf den Wert 3600 steigen kann, sondern auf 900 begrenzt ist. Es steht auch im Kommentar "25% of the hourly budget". Es fehlt aber eine Begründung, warum das auf 25% begrenzt ist. Kann ich den Wert für MAX_CREDIT auf 3600 erhöhen? Oder habe ich etwas noch nicht verstanden?

 - Michael

Hausautomat

Hallo zusammen,

LOVF habe ich heute erstmals bei meiner Installation erhalten - ohne dass ich Veränderungen an der Hardware (unverändert 13 FK, 5 HT) vorgenommen habe. Davon läuft derzeit sogar nur ein Teil über den CUL, der Rest ist noch über den CUBE angeschlossen.

Die einzige wesentliche Veränderung war gestern die Einspielung der 1.50er CUL_V4-Firmware. Natürlich kam auch ein Update in fhem dazu ;-).

Zu der Zeit der LOVFs finden auch keine Umstellungen der HTs statt und die FK senden alle einmal in der Stunde, das passt auch nicht als Grund.

Ist für die Berechnung das Gesamtsystem relevant, also alle drei CUL/CUNOs sowie der CUBE relevant?

Matthias Gehre

Ja, die culfw im MAX Modus hält sich jetzt auch an die gesetzlichen Vorschriften
und benutzt dazu das gleiche Framework wie die anderen culfw Module.

Warum jedoch MAX_CREDIT 900 ist, weiß ich nicht. Das war schon lange vor meiner Zeit da :-)

Hausautomat

Hm. Aber ich erreiche doch  nicht mit ein paar ACK-Pongs bei FK öffnen-schliessen gleich soviele Nachrichtne, dass zu den Zeiten (Morgens und Abends) gleich der Credit aufgebraucht ist? Das sind doch nur sehr kurze Telegramme. Und es ist auch nicht nur ein LOVF, sondern gleich ein Sack voll (also innerhalb der Stunde, nachdem wir heim kommen (2X Tür auf-zu, Bad Fenster auf-zu, das war's im Wesentlichen, keine HT-Aktivität) kommen über 30 LOVF-Meldungen im Log zusammen.

Ich kann anbieten, den Log-Level mal hoch zu drehen, damit jede MAX-Nachricht geloggt wird. Keine Ahnung, ob das hilft.

Michael N.

Was hilft ist, bei dem verwendeten CUL das Attribut loglevel auf 2 zu setzen. Dann erscheinen die gesendeten ("SW:...") und empfangenen Pakete im Log-File. Bei den gesendeten Paketen sind die Hex-Ziffer 15-20 die Adresse an die gesendet wird. Damit weißt Du, an wen gesendet wird. Warum gesendet wird, musst Du aus Deinen Regeln herausbekommen.

 - Michael

Hausautomat

Klar, das war ja Sinn meiner Frage :-)

Werde ich mal hochschalten, melde Erkenntnisse.

Hausautomat

Ok, hier mal die Ereignisse, die zu dem LOVF führen. Den über den CUBE laufenden Verkehr, der natürlich auch vom MCUL mitgeloggt wird, habe ich mal ausgeblendet.

Erläuterung der Geräte habe ich mal hintergeschrieben. Mehr Verkehr ist in der Stunde nicht über SW gelaufen. 123456 ist der MCUL.

2013.01.08 21:34:31 2: MCUL: Z0B5A06300070051234560010 -65.5 (Haustür Status zu)
2013.01.08 21:34:31 2: SW: Zs0b5A00021234560070050000              (Ack darauf)
2013.01.08 21:36:54 2: MCUL: Z0BB406300051C01234560010 -58         (WC Fenster Status zu)
2013.01.08 21:36:54 2: SW: Zs0bB400021234560051c00000              (Ack darauf)
2013.01.08 21:40:26 2: MCUL: Z0BB10630005C8C1234560010 -68.5       (Küche Fenster Status zu)
2013.01.08 21:40:27 2: SW: Zs0bB10002123456005c8c0000              (Ack darauf)
2013.01.08 21:48:40 2: MCUL: Z0BFC06300053151234560012 -92.5       (WoZiTür1 Auf)
2013.01.08 21:48:40 2: SW: Zs0bFC00021234560053150000              (Ack darauf)
2013.01.08 21:48:43 2: MCUL: Z0BFC06300053151234560052 -86.5       (nochmal WoZiTür1 Auf mit 52 statt 02? Ack nicht angekommen?)
2013.01.08 21:48:43 2: SW: Zs0bFC00021234560053150000              (Ack - darauf)
2013.01.08 21:48:50 2: MCUL: Z0BFC06300053151234560052 -89.5       (zweites mal WoZiTür1 Auf mit "52")
2013.01.08 21:48:50 2: SW: Zs0bFC00021234560053150000              (Ack - ebenfalls erneut)
2013.01.08 21:49:03 2: MCUL: Z0BFC06300053151234560052 -87         (drittes mal WoZiTür1 Auf mit "52")
2013.01.08 21:49:03 2: SW: Zs0bFC00021234560053150000              (Ack - ebenfalls drittes mal)
2013.01.08 21:50:28 2: SW: Zs0f690303123456005315000d08143256      (Was sendet der MCUL hier an die WoZiTür1 hier?)
2013.01.08 21:50:28 2: SW: Zs0f690303123456007005000d08143256      (gleiches an die HausTür?)
2013.01.08 21:50:31 2: CUL_MAX_Resend: Missing ack from 005315 for 0f690303123456005315000d08143256
2013.01.08 21:50:31 1: CUL_MAX_Resend: Giving up on that packet    (Paket wird vom WoZiTür nicht ack'd)
2013.01.08 21:50:31 2: SW: Zs0f6903031234560051c0000d08143256      (gleiches an's WCFenster)
2013.01.08 21:50:32 2: CUL_MAX_Resend: Missing ack from 007005 for 0f690303123456007005000d08143256
2013.01.08 21:50:32 1: CUL_MAX_Resend: Giving up on that packet    (klappt auch nicht bei HausTür)
2013.01.08 21:50:34 2: SW: Zs0f160303123456000b9c000d08143256      (gleiches an's HWRFenster)
2013.01.08 21:50:35 2: CUL_MAX_Resend: Missing ack from 0051c0 for 0f6903031234560051c0000d08143256
2013.01.08 21:50:35 1: CUL_MAX_Resend: Giving up on that packet    (klappt nicht an WCFenster)
2013.01.08 21:50:37 2: SW: Zs0f690303123456005c8c000d08143256      (gleiches an KücheFenster)
2013.01.08 21:50:38 2: CUL_MAX_Resend: Missing ack from 000b9c for 0f160303123456000b9c000d08143256
2013.01.08 21:50:38 1: CUL_MAX_Resend: Giving up on that packet    (geht auch nicht)
2013.01.08 21:50:40 2: SW: Zs0ff4030312345602608b000d08143256      (Und an's Bad-HeizkörperThermostat)
2013.01.08 21:50:41 2: MCUL: LOVF                                  -> Vorbei.
2013.01.08 21:50:41 2: MCUL: unknown message LOVF
2013.01.08 21:50:41 2: CUL_MAX_Resend: Missing ack from 005c8c for 0f690303123456005c8c000d08143256
2013.01.08 21:50:41 1: CUL_MAX_Resend: Giving up on that packet
2013.01.08 21:50:44 2: CUL_MAX_Resend: Missing ack from 02608b for 0ff4030312345602608b000d08143256
2013.01.08 21:50:44 1: CUL_MAX_Resend: Giving up on that packet
2013.01.08 21:53:40 2: MCUL: Z0BFD06300053151234560010 -83
2013.01.08 21:53:40 2: SW: Zs0bFD00021234560053150000


Was ist denn die Nachricht 000d08143256 (Cmd 0303 - Timeinformation?) an die Fensterkontakte, die hier gesendet, von den FK aber nicht Ack'd wird (klar, denen ist die Uhr völlig egal)? Die FK sind doch keine "Empfänger", die regelmäßig abgefragt werden? Die senden doch ungefragt einmal die Stunde den Status.

Aber selbst, wenn das alles zusammengenommen wird - das wären drei (?) Resends pro Gegenstelle (hier: 6 Stück) und bis dahin seit 21h 7xACK, die gesendet wurden. Ist das schon über dem Sendelimit?

Danke & Gruß

Michael N.

Gehen wir mal von einem Sendezeitguthaben von 900*10ms um 21:34 aus. Das reicht für ca. 8 messages à 1,1s (1s ist allein die Preamble). Sobald von den 900 etwas verbraucht ist, steigt das Guthaben allerdings auch wieder um 1 (10ms) pro Sekunde. Ab 21:34 ist der Verbrauch größer als die Gutschriften (geschätzt, kann sein, dass auch noch mal die 900 erreicht werden und Guthaben verloren geht, so genau habe ich nicht nachgerechnet). Also kommen alle Gutschriften "zum Zuge", d.h. von 21:34-21:50 kommt wieder Guthaben für ca. weitere 8 Messages hinzu. Das wäre insgesamt Guthaben für 16 Messages. LOVF kommt nach der 13. Message, also etwas früher. Aber im Rahmen der Abschätzung kommt es ganz gut hin (vielleicht waren es ja auch nicht wirklich 900 am Anfang), LOVF ist also (bei MAX_CREDIT 900) berechtigt.

Meiner Meinung nach müsste MAX_CREDIT 3600 sein, dann wäre "mehr Luft" für solche "geballten" Aktivitäten. Letztlich kann es aber sein. dass größere MAX Installationen ohnehin nur mit LBT (statt 1% Regel) sinnvoll betrieben werden können.

 - Michael

Matthias Gehre

Dazu:
1. TimeInformation übermittelt alle 6 Stunden die aktuelle Zeit. Allerdings sollte das nur an Thermostate gesendet werden. Fix kommt demnächst.
2. m.E. spricht nichts gegen MAX_CREDIT 3600
3. Listen-before-talk ist bereits implementiert. Der CC1101 hat das hardwaremäßig drin (heißt dort CCA) und wird vom Moritz Modul auch aktiviert.
  Bei meinem letzten Gespräch mit den culfw Entwicklern wurde mir nicht klar, ob CCA reicht, um die 1%-Regel zu deaktivieren. Ist das so?

Michael N.

Bis 2010 war die Frage einfach zu beantworten. Da stand in den Vefügungen 1% oder LBT -- also LBT reicht.

In der letzten Verfügung (Vfg 40/2010) der Bundesnetzagentur steht "Es sind Frequenzzugangs- und Störungsminderungstechniken einzusetzen, deren Leistung mindestens den Techniken entspricht, die in den gemäß Richtlinie 1999/5/EG bzw. des FTEG verabschiedeten harmonisierten Normen vorgesehen sind." oder, alternativ, maximaler Arbeitszyklus 1%.

Damit wird es etwas kompliziert, denn ich kann den Verweis auf die "harmonisierten Normen" nicht so einfach auflösen. Weiß jemand mehr?

 - Michael

Michael N.

OK, ich glaube ich habe es. Die harmonisierten Normen sind ETSI EN 300 220-1 und EN 300 220-2. Damit ist LPT tot, da es nur noch in Kombination mit AFA (Adaptive Frequency Agility) zulässig ist.

 - Michael

Hausautomat

Das habe ich verstanden.

Mit dem MAX_CREDIT 900 - in der Firmware habe ich jetzt nicht nachvollzogen, ob die Betrachtung in der Tat per viertel Stunde ist (dann wäre ja 900 korrekt) oder per Stunde (dann müsste es natürlich hochgesetzt werden).

@Matthias
Für 14_CUL_MAX.pm habe ich hier lokal einen kurz-Patch eingestellt (anbei). Der Broadcast-Time wird dann überhaupt nur eingerichtet, wenn der TYPE ein .*Thermostat.* ist. Das wäre in Deinem Sinne? Lediglich für Set (setting) habe ich keine Fehlerroutine drin ;-), wird still einfach nur nicht aufgesetzt, wenn es kein Thermostat ist.

Hat hier zumindest mal fehlerfrei gestartet, habe aber vergessen, den Loglevel hochzudrehen.

Gruß
 Jens

Matthias Gehre

Danke für den Patch, habs aber jetzt erst gelesen und mein Fix ist schon committed.

M.E. müsste es MAX_CREDIT 3600 sein. Dann ist sichergestellt, das in jedem Zeitfenster
von einer Stunden (egal wann es anfängt) nicht mehr als 1% der Zeit (also 36 Sekunden lang)
gesendet wird.

Oder gibt's auch eine Regel, dass man nicht 36 Sekunden am Stück senden darf (und dann eine Stunde lang nicht mehr)?

Tobias

ich habe ebenfalls das LOVF Problem. Nur ein(!) Fensterkontakt und ein(!) Thermostat und schon bei 3-4mal Fenster öffnen kommt die LOVF Meldung. Und das, obwohl IMHO der CUL nur ein ACK sendet?? Und genau dann gibts auch die Probleme das das Thermostat bei der "FensterOffen"Meldung nicht selbstständig auf die "WindowOpenTemperature" schaltet.
Der Status des FK in fhem wechselt beim öffnen auf "opened", und 1sek danach auf "opened (rf error)". Beim Schließen dasselbe.
Im Log des Fensterkontaktes fällt mir auf, das nach dem Öffnen oder Schließen der Fensterkontakt exakt immer 5x innerhalb von 1min der Status erneut übermittelt wird.
Zitat2013-01-11_05:27:05 WZ_Fenster battery: ok
2013-01-11_05:27:05 WZ_Fenster onoff: 1
2013-01-11_05:27:10 WZ_Fenster battery: ok
2013-01-11_05:27:10 WZ_Fenster onoff: 1
2013-01-11_05:27:19 WZ_Fenster battery: ok
2013-01-11_05:27:19 WZ_Fenster onoff: 1
2013-01-11_05:27:34 WZ_Fenster battery: ok
2013-01-11_05:27:34 WZ_Fenster onoff: 1
2013-01-11_05:28:01 WZ_Fenster battery: ok
2013-01-11_05:28:01 WZ_Fenster onoff: 1
Ist das ein normales Verhalten des FK? Dementsprechend müsste der CUL ja auch 5x ACK senden. Oder Fragt der CUL mehrmals nach?
Ist das bei Euch auch so?

Hat jetzt die per fhem ausgelieferte CUL_V3.hex einen angepassten MAX_CREDIT?
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

Tobias

korrektur: beim 2mal öffnen gabs schon LOVF

5:28: Fenster auf
5:43: Fenster zu
5:46: Fenster auf
5:47: Fenster zu -> LOVF

und jedes mal jeweils die 5 Meldungen im FK-Log. Zwischendurch kam noch die Schließmeldung und wieder-Öffnungsmeldung des Thermostates

Ganz zu schweigen wie LOVF ausschaut wenn ich im ganzen Haus MAX einsetze (15 Thermostate) :(
Bei meinem FS20-CUL mit viel FS20 Schaltern hatte ich noch nie LOVF
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

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?

Matthias Gehre

Es gibt keine Kabel in der Luft, wir empfangen also wohl oder übel auch alle Pakete von unseren Nachbarn.

Warum sollte die Lösung nicht mit mehreren Kontakten funktionieren? Mit Za wird unsere Adresse programmiert,
nicht die des Fensterkontakts. Sie wird mit dem Empfänger der ShutterContactState Nachricht verglichen, nicht mit dem Absender.

Michael N.

Zitat von: Matthias Gehre schrieb am So, 13 Januar 2013 04:00Mit Za wird unsere Adresse programmiert,
nicht die des Fensterkontakts.

Danke! Das war mein Missverständnis! Ich dachte mit "Za" wird die Adresse des Fensterkontakts programmiert, weil die eigene Adresse ja schon die ganze Zeit (also schon vor der letzten Änderung) bekannt war. Aber -- natürlich -- sie war bislang nur dem "cm" bekannt und wurde vorher nicht an den CUL übermittelt. (Und ACK über den Umweg über FHEM dauert zu lange.) Ich denke jetzt hab' ich es.

Tobias

ich habe eben das aktuelle CUL_V3.hex aus dem svn auf meinen CUL geflashed, aber der Fensterkontakt bestätigt ein Öffnen/Schließen immer noch mit 3x blinken (Befehl nicht erfolgreich übertragen, ACK fehlt) und in fhem steht dann auch "xxxxx (rf error)"

ideen?
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

Bei mir funktioniert es seit einigen Tagen nun ohne Probleme.

Wir laut Log der Befehl "Za...." abgesetzt?
Im Moment tue ich das nämlich in CUL_MAX_define. Wenn da allerdings noch kein CUL mit neuer Firmware gefunden wird,
dann macht er das nicht (auf alten Firmwares würde es den MAX Modus deaktivieren)

D.h. nach dem erstmaligen Flashen auf neue die Firmware muss man danach Za... per Hand absetzen oder FHEM neustarten.
Der Za... Teil müsste am besten noch noch 00_CUL wandern, so in die Richtung initString.

Tobias

alles, klar. nach einem update und restart scheint es nun zu funktionieren.
Aus dem obigen Text hat sich das so herausgelesen, das nur culfw angepasst wurde.

Ist jetzt MAX_CREDIT auch auf 3600?
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

Nein, weil ich immer noch nicht weiß, warum jemand ursprünglich 900 hingeschrieben hat. Dafür gab es bestimmt einen Grund.
Alternativ wäre auch ein Okey von einem der "älteren" CULfw Programmierer gut.

Hausautomat

Hallo Matthias,

das ist echt klasse. Jetzt blinkt der FK nur noch einmal, das ACK von der culfw kommt also korrekt an.
Damit sollte auch in etwas größeren Installationen das LOVF-Thema zumindest um einiges nach hinten geschoben werden bzw. nicht mehr vom Lüftungsverhalten ;-) abhängen.

Leider bin ich erst heute zum Update gekommen.

Werde mal in 00_CUL schauen - Du hast ja recht, dass es als Teil des CUL-Setups dorthin gehört - nach Prüfung der passenden Firmware.
Bitte keine zeitlichen Wunder erwarten :-).

Gruß
 Jens