Autor Thema: Warum MAX_CREDIT 900?  (Gelesen 17544 mal)

Offline Michael N.

  • New Member
  • *
  • Beiträge: 31
Warum MAX_CREDIT 900?
« am: 04 Januar 2013, 12:43:57 »
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

Offline Hausautomat

  • Full Member
  • ***
  • Beiträge: 128
Aw: Warum MAX_CREDIT 900?
« Antwort #1 am: 07 Januar 2013, 20:21:31 »
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?

Offline Matthias Gehre

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 707
Aw: Warum MAX_CREDIT 900?
« Antwort #2 am: 08 Januar 2013, 00:46:05 »
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 :-)

Offline Hausautomat

  • Full Member
  • ***
  • Beiträge: 128
Aw: Warum MAX_CREDIT 900?
« Antwort #3 am: 08 Januar 2013, 20:09:11 »
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.

Offline Michael N.

  • New Member
  • *
  • Beiträge: 31
Aw: Warum MAX_CREDIT 900?
« Antwort #4 am: 08 Januar 2013, 21:05:45 »
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

Offline Hausautomat

  • Full Member
  • ***
  • Beiträge: 128
Aw: Warum MAX_CREDIT 900?
« Antwort #5 am: 08 Januar 2013, 21:07:18 »
Klar, das war ja Sinn meiner Frage :-)

Werde ich mal hochschalten, melde Erkenntnisse.

Offline Hausautomat

  • Full Member
  • ***
  • Beiträge: 128
Aw: Warum MAX_CREDIT 900?
« Antwort #6 am: 08 Januar 2013, 22:28:51 »
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ß

Offline Michael N.

  • New Member
  • *
  • Beiträge: 31
Aw: Warum MAX_CREDIT 900?
« Antwort #7 am: 08 Januar 2013, 23:09:18 »
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

Offline Matthias Gehre

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 707
Aw: Warum MAX_CREDIT 900?
« Antwort #8 am: 09 Januar 2013, 12:07:14 »
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?

Offline Michael N.

  • New Member
  • *
  • Beiträge: 31
Aw: Warum MAX_CREDIT 900?
« Antwort #9 am: 09 Januar 2013, 14:35:08 »
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

Offline Michael N.

  • New Member
  • *
  • Beiträge: 31
Aw: Warum MAX_CREDIT 900?
« Antwort #10 am: 09 Januar 2013, 16:04:31 »
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

Offline Hausautomat

  • Full Member
  • ***
  • Beiträge: 128
Aw: Warum MAX_CREDIT 900?
« Antwort #11 am: 09 Januar 2013, 21:49:29 »
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

Offline Matthias Gehre

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 707
Aw: Warum MAX_CREDIT 900?
« Antwort #12 am: 10 Januar 2013, 13:55:34 »
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)?

Offline Tobias

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3936
Aw: Warum MAX_CREDIT 900?
« Antwort #13 am: 11 Januar 2013, 07:57:25 »
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.
Zitat
2013-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?
FHEM auf ASRock J3455-ITX im 19" Rack mit Homematic, MAX, PCA301, Panstamps, RPi für BLE Bodenfeuchtesenoren, Text2Speech.
Maintainer der Module: Text2Speech, TrashCal, MediaList

Meine Projekte auf https://github.com/tobiasfaust
u.a. PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM

Offline Tobias

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3936
Aw: Warum MAX_CREDIT 900?
« Antwort #14 am: 11 Januar 2013, 08:05:46 »
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
FHEM auf ASRock J3455-ITX im 19" Rack mit Homematic, MAX, PCA301, Panstamps, RPi für BLE Bodenfeuchtesenoren, Text2Speech.
Maintainer der Module: Text2Speech, TrashCal, MediaList

Meine Projekte auf https://github.com/tobiasfaust
u.a. PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM

 

decade-submarginal