unknown message LOVF

Begonnen von h-man-kl, 20 September 2016, 12:38:48

Vorheriges Thema - Nächstes Thema

RaspiCOC

Zitatden RSSI Wert nie über -85  ( -89 ist in der Regel zu schlecht) kommen lassen

Guter Punkt!

Aber, auch wenn jetzt die Duty Cycle Verfechter mich dafür grillen mögen, seit meinem Einsatz eines zweiten COC / CUL / CUN / ... wasauchimmer sind bei mir keine Probleme mehr vorhanden. Ich hatte irgendwo mal gelesen, dass 10 FHTs so ziemlich das Maximum sind. Ich halte diese Zahl schon für sehr optimistisch. Aktuell fahre ich mit 6 FHT pro COC und alles ist gut.

h-man-kl

Ich habe jetzt folgendes gemacht:
zusätzlich wieder die alte FHZ USB angeschlossen und dort die FHTs wieder angemeldet. Somit habe ich was den Empfang angeht wieder die Sietuation wie ich sie "schon immer" hatte.
das AT habe ich aus um sicher zu gehen dass da nix mehr geschickt wird.
Ich warte jetzt mal ein paar Tage und dann stelle ich die Uhren ganz oldschool manuel an den FHTs. Die dürften sch ja dann nicht mehr verstellen; zumindest nicht im Stundenbereich.

Ich melde mich dnn wieder.
RasPi 3 mit MaxCube für FS20 , HM-Urart, HM-LAN, MiLight, HUE, Lightify, SONOS, Harmony, Unifi, FritzBox 7490... :-)
Ganz nach dem Motto: Normal? Normal is langweilig....

LudgerR

@RaspiCOC

das mit "Duty Cycle Verfechter "  nehme ich nun sportlich.

Habe gerade zwei weitere Reserve FHT80b  zusätzlich zu meinen 7 FHTs  im  Erdgeschoss in Betrieb genommen.
Steuere somit 9 FHTs im EG von einem CUNO (weitere 6 FHTs im OG von einem zweiten CUNO).

Bei allen Geräten wird

  o  Zweimal am Tag die Uhrzeit übertragen (zwischen 11 und 18 Uhr) 
  o   Einmal Abends die m FHT gespeicherten  Ereignispunkte für den Folgetag per "report1" angefordert
  o   Einmal früh morgens  per holiday_short  die Abweichung  von der normalen Aufstehzeit
       (=> zeitgleicher Wechsel von Nacht- auf Tagestemeratur bei allen FHTs)

Per "get CUNO rawT02"  überwache ich alle 15 Minten die Telegramme in den Queues.  Falls ein Befehl länger als 15 Minuten in der Queue verweilt log ich ihn und ermittle das zugehörige FHT device.  Die Ursache war bei mir entweder zu hoher RSSI Wert oder das Gerät war schon nicht mehr der Centralen (CUNO) zugeordnet.

Werde mal in den nächsten Tagen ein Update geben ob 9 Geräte zuviel sind oder sogar 10 möglich sind.

VG
LudgerR
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

LudgerR

Nun mein feedback von meinen Test mit 9 FHT80b an einem CUNO.

Das ganze funktioniert mit 9 FHTS problemlos, solange ich nicht während des Tages zeitgleich an mehr als einem FHT  Temperatur und/oder Mode Änderungen durchführe. Mit 10 Geräten ändert sich dies schlagartig, weil dann der Buffer in der CUNO für die Verarbeitung der ein und ausgehenden Telegramme nicht mehr ausreicht.   

Ich vermute, dass einer ähnlicher Effekt beim MAX Cube bereits bei 6 bis 8 Geräten oder weniger zu Tage tritt.

Mein Vorschlag:  Nicht alle Geräte gleichzeitig am Max Cube anmelden und beobachten wie es sich bei 3,4 oder 5 FHTs verhält.

Erkenntnis für mich:   Bei Bedarf  kann ich  mein Steuerung von 7 FHTs bedenkenlos auf 8 Geräte erweitern.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

RaspiCOC

Mit 8 bis 9 FHT bist Du absolut an der Grenze der sinnvoll machbaren. Bei 10 oder 12 geht gar nichts mehr, auch wenn die Spezifikation der FHZ1000 von 12 ausgeht. Mit 12 FHT habe ich ein ganzes Wochenende gebraucht, um von Absenkbetrieb auf Normalbetrieb zu kommen. Meines Erachtens ist die sinnvolle und responsive Grenze bei 6 oder 7 FHT. Alles andere ist nicht mehr zu empfehlen!

LudgerR

Richtig 8 bis 9  FHTs ist das Limit und funktioniert auch nur, wenn man sie ,,artgerecht" einsetzt. D.h. Schaltprogramme sollten tunlichst in den Geräten selbst gespeichert werden und der Normalbetrieb ist der Autobetrieb. So wie ich das verstanden habe verfährst Du auch so.
Ein Tipp von mir.  Der mode holiday und holiday_short  ist hervorragend geeignet  um zeitgleich  alle FHTs nach einer Abwesenheit zur geplanten Rückkehrzeit wieder in den Automatikbetrieb (mit korrekter Tages- und Nachttemperatur) zu setzten.  Das Problem, dass es bei ungeplantem Abwesenheit es einige Zeit dauert bis all Geräte in den holiday(_short) Betrieb mit Absenktemperatur wechseln, habe ich dadurch gelöst, dass ich der Gastherme direkt bei Verlassen der Wohnung eine Außentemperatur von mehr als 30 Grad vorgaukle und nicht erst warte bis alle Ventile der FHTs auf 0 sind. Und da ich diese Funktion jeden Tag für die adhoc Manipulation der Aufstehzeit verwende (und somit teste), kann ich mich auch darauf verlassen, dass dies dann auch für meine Abwesenheitssteuerung funktioniert.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

h-man-kl

Hallo zusammen,
inzwischen sind ja wieder ein paar Tage rum. Die Uhrzeiten haben sich nicht mehr "selbst" verstellt. Allerdings habe ich auch keinen Befehl mehr zum Verstellen geschickt.
Ich werde jetzt mal testen wie sich das ganze Verhält wenn ich jetzt mal einem Regler eine Zeit schicke.

Ich kann allerdings eure Problem mit der 1% Regelung nicht bestätigen. Ich habe 2x 8 FHTs (in zwei Häusern - also völlig getrennt voneinander) mit einer FHZ1000 und einer FHZ1300 über das alte Homputer-System am laufen. Bzw. 1 läuft noch s und das andere ist a jetzt FHEM. Dort habe ich nirgends die Automatik an sondern sende so 4 -8x am Tag die gewünschten Temperaturen. Die Uhren haben sic über das System immer automatisch gestellt. Probleme mit der 1% Auslastung hatte ich keine.

Aktuell vermute ich wirklich, dass der MAX Cube nicht so optimal zu den FHTs passt wie die FHZ1300.  Ich warte jetzt mal ab wie es läuft. 
RasPi 3 mit MaxCube für FS20 , HM-Urart, HM-LAN, MiLight, HUE, Lightify, SONOS, Harmony, Unifi, FritzBox 7490... :-)
Ganz nach dem Motto: Normal? Normal is langweilig....

LudgerR

Hallo,

es geht nicht um die 1% Regelung, sondern um den Speicher des Funkdevices (bei mir CUNO) der gemeinsam für ein- und ausgehende Telegramme verwendet wird.  Bei 9 FHTs sehe ich dass der Puffer sporadisch sehr stark durch eingehende Status Meldungen belegt wird. Für ausgehende FHT set Befehle steht dann noch wenig Speicherplatz zur Verfügung und es kommt dann zu Sendewiederholungen, die wiederum mangels Speicherplatz scheitern.  Bei mir kommen noch zahlreiche Status Meldungen von EM und HMS Geräten hinzu (Gas-, Stromzähler, Wasser, Luftfeuchte- und Wassermelder). Ohne diese läge bei mir das Limit bei 10 statt 9 FHTs. Bei derzeit 9 FHTs werden die set Befehle an die FHTs immer in weniger als 15 Minuten abgearbeitet.

Den Auto-Betrieb habe ich bewusst gewählt:

  o  weniger Funkverkehr (zwischen FHT und CUNO)
  o  exakte Schaltzeiten
  o  Ausfallsicherheit (FHTs wechseln zwischen Tag- und Nachttemp. auch ohne fhem)
 

 
     
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

h-man-kl

Hallo,
also ich kapiere es imer noch nicht. Habe gestern versucht über fhem die Uhrzeit an einem Regler zu stellen. => nix ist passiert. Das stellen der Temperatur hingegen klappt.

Ihr habt ja recht, dass der Automatikbetrieb der "sicherere" Weg ist, aber ich finde fhem da recht unkomfortabel um die Zeiten zu Programieren. Da ich ja jetzt wieder die FHZ dran habe müsste ich eigentlich  wenn ich die wieder an meinen alten PC stecke die Zeittabellen eingeben können, da ja die FHTs mit der FHZ gepair sind und nicht mit fhem, oder?
Ist ja bei Homatickomponente auch so.

Aber all das ändert nichts an dem seltsamen Verhalten.
RasPi 3 mit MaxCube für FS20 , HM-Urart, HM-LAN, MiLight, HUE, Lightify, SONOS, Harmony, Unifi, FritzBox 7490... :-)
Ganz nach dem Motto: Normal? Normal is langweilig....

LudgerR

Mit MAX Cube habe  ich mich nicht beschäftigt.  Ist auf dem Gerät  culfw (Firmware) geflasht?
Wenn ja, müssten  man sich  ja auch mit  ,,get  MyCul   raw  T02" sich die ausgehenden FHT Telegramme anzeigen lassen.

Da man bis zu acht FHT Befehle in einem einzigen set Befehl absetzen kann, würde ich die Uhrzeit zusammen mit einem abschließenden desired-temp  Befehl in einem set Befehl senden und mir anschauen was passiert.

Z.B. führt der set Befehl

set FHT_Kueche time desired-temp 19
bei  " get CUNO 2 raw T02"  zu folgender Anzeige bei mir
CUNO2 raw => 2F46:630F,6407,4126
Das obige Telegramm enthält die Adresse (CODE)  2F46 von  FHT_Kueche gefolgt von Stunde, Minute und gewünschter Temperatur in codierter Form. Die Information wird in einem Telegramm ans FHT Gerät übertragen. 

Entweder kommt beides zusammen am FHT-Gerät an oder die Nachricht bleibt im Pufferspeicher hängen.  Dein Phänomen Temperatur wird übertragen, Uhrzeit jedoch nicht ist mir noch nicht untergekommen.

----

Die im FHT gespeicherten Wochenpläne bleiben  beim Wechsel  der Centralen  (d.h. von FHZ nach  CUL / MAX Cube)  erhalten.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

h-man-kl

Ich sehe mir bei Gelegenheit den befehl mal an.
Aktuell denke ich, dass mein einer FHT defekt ist, oder dass es bei mir im Bad zu einer Verschiebung des Raum / Zeit kontinuums gekommen ist => jeden Morgen ist der 16.10. und eine völlig wirre Uhrzeit. Das kann ja nicht sein. Allerdings gehen meine anderen FHTs auch falsch. An einem habe ich in den letzten 2 wochen 10 Minuten Zeitverschwendung gehabt. Das hatte ich früher nie.

Steuern lassen sich die beiden aber ganz normal über fhem.
Deswegen verstehe ich das ja nicht.

Gruß
H-man
RasPi 3 mit MaxCube für FS20 , HM-Urart, HM-LAN, MiLight, HUE, Lightify, SONOS, Harmony, Unifi, FritzBox 7490... :-)
Ganz nach dem Motto: Normal? Normal is langweilig....