RaspberryMatic 3.53.30.20200919 – Neue Version

[roe1974]

Also ich stelle hier nur einen leicht erhöhten „Base-DC“ fest .... der war vorher bei 4% ... selten über 10% .... jetzt ist er bei 6-8% und klettert auf 13-14% .... aber sonst läuft alles perfekt !!
lg und Danke !!!!!
Richard

[Raspihausfan_1]

Heute hatte ich bereits 2 mal diese Fehlermeldung:

Ich nutze Tinkerboard S und hatte so eine Alarmmeldung noch nicht. Nun ist ja Onboard eine Uhr verbaut. Eigentlich sollte diese einspringen und sich nicht wegducken.

[Hütte]

...
Jedoch - trotzdem seit Samstag eben vermehrt immer wieder ganz kurze Komm Fehler quer durch die Bank im IP Bereich. Wollen die den HAP nicht oder stört der noch eingschaltete Router-Mode auf den diversen PS (M)s ?
...

Wenn ich mich richtig erinnere bei den ganzen Beiträgen zum HAP als LAN-Gateway (auch im Unterforum, bei dem es um die Original CCU-Firmware geht), dann war Ruhe im Karton, nachdem bei den PS (M) der Router-Mode abgeschaltet wurde.

P.S. aktuell werden nur max. 2 IP-LAN-Gateways unterstützt. Wenn also bereits ein DRAP im Einsatz ist, dann kann nur noch ein HAP als Gateway hinzukommen. Bei 2 DRAP's im Einsatz, dann aktuell kein HAP mehr möglich. Und wenn kein DRAP, dann aktuell 2 HAP's möglich. Die Anzahl soll aber in Zukunft noch erweitert werden.

[Michel2017]

Also ich stelle hier nur einen leicht erhöhten „Base-DC“ fest .... der war vorher bei 4% ... selten über 10% .... jetzt ist er bei 6-8% und klettert auf 13-14% .... aber sonst läuft alles perfekt !!
lg und Danke !!!!!
Richard

Kann ich bestätigen...Über Nacht, wenn alles ruhig ist, habe ich immer einen DC von 1-2% (mit ein oder zwei Spitzen von 3%). Nun ist er (ohne irgendwas verändert zu haben) 4-5%...Werte kleiner als 4 scheint es gar nicht mehr zu geben...

[MichaelN]

Zu deinem Punkt 2. Das sieht bei mir bei den BROLL auch so aus und Nein, es war vorher nicht so. Da bin ich mir sicher.

Ich habe kein Update gemacht und die Original CCU - da sieht das auch so aus und war schon "immer" so. Zumindest war es in 3.51.6 so.

[onkeltommy]

...
Jedoch - trotzdem seit Samstag eben vermehrt immer wieder ganz kurze Komm Fehler quer durch die Bank im IP Bereich. Wollen die den HAP nicht oder stört der noch eingschaltete Router-Mode auf den diversen PS (M)s ?
...

Wenn ich mich richtig erinnere bei den ganzen Beiträgen zum HAP als LAN-Gateway (auch im Unterforum, bei dem es um die Original CCU-Firmware geht), dann war Ruhe im Karton, nachdem bei den PS (M) der Router-Mode abgeschaltet wurde.

P.S. aktuell werden nur max. 2 IP-LAN-Gateways unterstützt. Wenn also bereits ein DRAP im Einsatz ist, dann kann nur noch ein HAP als Gateway hinzukommen. Bei 2 DRAP's im Einsatz, dann aktuell kein HAP mehr möglich. Und wenn kein DRAP, dann aktuell 2 HAP's möglich. Die Anzahl soll aber in Zukunft noch erweitert werden.

Okay, das ist ein guter Hinweis, ich habe jetzt bei allen den Routermode (Gerät dient als Router) schon vor ca. 2h ausgeschaltet.
Ist auch ein neuer Punkt dazugekommen - Multicast- aber die Funktion is eigentlich klar.
Eine Funktion ist noch bei allen aktiv, die Dritte, Routing aktiv. Sollte die auch weg ? Oder bezieht sich das nur auf DVs - also wenn die PS(M) Probleme hat den direkten Partner zu erreichen um dann über einen HAP oder über die Zentrale zu gehen ?

[Strunzdesign]

@onkeltommy: mich wundert aktuell vor Allem die Funktion "Routing aktiv" beim HAP selbst. Da dieser ja über Ethernet die CCU erreicht, ist diese Option doch unsinnig, oder? Zumindest muss sie etwas anderes bedeuten als bei einem drahtlosen HmIP-Gerät. Ich kann mir nur erklären, dass es hierbei um den "Downlink" zu anderen HmIP-Geräten gehen soll, zum Beispiel nochmals über eine HmIP-PS hinweg. Aber wieso sollte man so etwas explizit an- und abwählen können?

Viele Grüße,
Florian

[SGubler]

Die Neuerungen lesen sich ja wie Weihnachten, Ostern und Geburtstag in einem!
ENDLICH gibt es ein HmIP-Gateway und mehr als ein HmIP-DRAW sind möglich, nun wird das System langsam erwachsen und skalierbar.
Danke an EQ3 und and das Team um Jens Maus.
Soweit die Theorie.

Das update auf Raspimatic Virtuell auf ESXi Verlief ohne Probleme. Zuerst hatte ich auch doppelte Einträge bei den Jalousien, aber nach Browser Cache löschen und Neustart war das dann weg.

Jetzt gings ans HAP testen. Ednlich gibt's so was und der Access Point kann endlich sinnvoll verwendet werden.
Der neue Homematic Access Point wurede heute geliefert. Angeschlossen und gewartet bis er blau leuchtete, eine fixe IP-Adress zugewiesen.
Dann über die Raspimatic die Firmware aktualisert und in der Homematic angelernt. Ging alles ganz flott.

Heute tagsüber habe ich getestet mit dem HAP im Keller. Ohne HAP ist die Verbindung zur CCU kanpp möglich Signalstärke - 99 bis -105 dbm.

Meine Testergebnisse sind durchwachsen, Zwei HmIP-STHD legte ich 1 Meter vom HAP entfernt. Dann sanken die RSSI Werte auf -50 dbm oder tiefer.
Hatte aber gefühlt Verzögerungen bei der Bedienung der Geräte über den HAP.

Danach wurden einer der HmIP-STHD 2 Meter weiter weg positioniert und der zweite HmIP-STHD in den angrenzenden Raum zurückgebracht.
Beide Sensoren haben wieder die RSSI Werte, welche sie vorher, ohne HAP hatten.
Obwohl in dem Raum auch noch ein HmIP-PCBS Modul mit Routerfunktion und im anderen Raum ein HmIP-PSM mit Routerfunktion steht sinken die RSSI Werte nicht.

Die HmIP Module mit Routerfunktion verwenden nicht konstant den HAP, sondern verbinden sich sehr oft direkt mit der CCU, obwohl der HAP gleich daneben steht.
Egal, ob "Gerät dienst als Router" aktiv ist oder nicht. (die Geräte hatte ich auch neu gestartet).


Was hat der HAP denn für eine Sendeleistung mit seiner Stummelantenne ? Muss da eine externe Antenne dran ?
Wie kann man das Kontrollieren und Debuggen, welche HMIP-Module den HAP verwenden und welche nicht ?

Der HAP teilt seinen Duty Cycle im Systemprotokoll mit, damit sollte es möglich sein, diesen auch darzustellen, zusammen mit den Duty Cycles der CCU+HM-LAN-GWs.


Ich bin gespannt auf die Testberichte anderer Benutzer hier im Forum.
Das mit dem HAP ist halt eine neue Funktion. Version 1.0 Gibt's dazu von offizieller Seite eine Doku oder eine Funktionsbeschreibung ?


Viele Grüsse

Stefan

[MathiasZ]

Ich denke, es ist an der Zeit, das WebUI-Handbuch zu aktualisieren.
Ich glaube auch nicht, dass man bereits HMIP-Geräte ohne weiteres tauschen kann, so wie man es von HM-Geräten gewohnt ist.
Das heißt, neues Gerät anlernen, altes Gerät löschen, alle Programme durchsehen und ggf ändern.
Es wäre auch schön zu sehen, welche HMIP-Geräte nun über der RM oder über der HAP laufen.
Gruß,
Mathias

[Raspihausfan_1]

Mittlerweile ist der Watchdog-Alarm 12 mal in der Nacht ausgelöst worden.
In der Logdatei findet man folgendes:

Code: Alles auswählen

Sep 23 22:04:54 localhost daemon.warn chronyd[781]: Forward time jump detected!
Sep 23 22:04:54 localhost daemon.info chronyd[781]: Can't synchronise: no selectable sources
Sep 23 22:08:08 localhost daemon.info chronyd[781]: Selected source 94.130.184.193
Sep 23 22:08:08 localhost daemon.warn chronyd[781]: System clock wrong by -3598.038366 seconds, adjustment started
Sep 23 22:09:06 localhost user.err monit[1299]: 'ntpOffsetCheck' status failed (20) -- +3598.038330078
Sep 23 22:09:06 localhost user.info monit[1299]: 'ntpOffsetCheck' exec: '/bin/triggerAlarm.tcl NTP offset > 1 second WatchDog-Alarm'
Sep 23 22:09:24 localhost user.err monit[1299]: 'ntpOffsetCheck' status failed (20) -- +3598.038330078
Sep 23 22:09:42 localhost user.info monit[1299]: 'ntpOffsetCheck' status succeeded (10) -- -0.000842978
Sep 23 23:04:45 localhost daemon.warn chronyd[781]: Forward time jump detected!
Sep 23 23:04:45 localhost daemon.info chronyd[781]: Can't synchronise: no selectable sources
Sep 23 23:07:58 localhost daemon.info chronyd[781]: Selected source 162.159.200.1
Sep 23 23:07:58 localhost daemon.warn chronyd[781]: System clock wrong by -3598.852760 seconds, adjustment started
Sep 23 23:08:58 localhost user.err monit[1299]: 'ntpOffsetCheck' status failed (20) -- +3598.852783203
Sep 23 23:08:58 localhost user.info monit[1299]: 'ntpOffsetCheck' exec: '/bin/triggerAlarm.tcl NTP offset > 1 second WatchDog-Alarm'
Sep 23 23:09:16 localhost user.err monit[1299]: 'ntpOffsetCheck' status failed (20) -- +3598.852783203
Sep 23 23:09:34 localhost user.info monit[1299]: 'ntpOffsetCheck' status succeeded (10) -- -0.003688353

An der Konfiguration wurde nichts geändert (Tinkerboard-S).
Die Fritzbox hat gestern Vormittag einen Neustart hingelegt. Das kann aber nicht dazu führen, dass es einen Watchdogalarm gibt. Heute früh gingen die Rolläden eine Stunde zu früh hoch.