RaspberryMatic 3.37.8.20181026 – Erfahrungsberichte

[keksn]

...keine Ahnung jedoch dürfte bei jedem erfolglosen Sendeversuch die die CPU last dramatisch steigen.

CPU Last? Mit der CPU hat das mal gar nichts zu tun...

Der Zusammenhang mit der Version 3.37.8.20181026 ist eindeutig und diese Frage stellt sich für mich nicht.
Ich habe unnötige Zusatzarbeiten gemacht, den Aktor(Autor ) getauscht, ich habe dem Aktor eine externe Antenne verpasst. Dann wieder alles zurück.

Schön... das bringt dir nur alles nichts, wenn dieser Aktor gar nicht das Problem ist.
Einem Aktor der Kommunikationsprobleme hat z.B. aufgrund der Entfernung zur CCU eine externe Antenne zu verpassen macht durchaus Sinn,
allerdings musst du das dann auch bei der CCU tun, sonst bringt das nichts.

Ich bleibe mal bei der Version 3.37.8.20180929 bis ein schlauerer Probleme mit der neuen Version bekommt und das Problem löst......Jens?

Wirst du wohl auch nun müssen, denn damit bin ich raus...

Du hast ja anscheinend keine Probleme mit der Version.....

[drose28357]

Wenn du in deinem Browser die Meldung einmal bestätigst, wird diese nicht mehr Angezeigt...

Tatsächlich nimmt der Browser jetzt die unsichere Version mit HTTP, zeigt das aber als unsicher an. Wie gesagt, das war in der vorherigen Version nicht der fall, dort funktionierte HTTPS. Ich bleibe dabei, das hier was schief gelaufen ist.
Gruß

[LibertyX]

Du kannst da gerne bei bleiben, Fakt ist aber, dass sich nichts geändert hat, es wird wie in allen vorangegangenen Versionen ein self-signed Zertifikat verwendet, was von allen aktuellen Browsern als "unsicher" angezeigt wird.

Nur weil die Verbindung als "unsicher" angezeigt wird, heißt das nicht das HTTPS (SSL) nicht funktioniert, in diesem Fall heißt es nur, dass er den Aussteller des Zertifikates nicht verifizieren kann. Die Verbindung aber SSL verschlüsselt und somit auch sicher ist, sofern der Host bekannt ist.

[andreasph]

Das der DC nach oben geht, wenn du einen Aktor mehrfach hintereinander ansteuerst (egal ob erreichbar oder nicht) ist normal und muss auch so sein.

Dann erkläre bitte auch warum der DC nach 13x senden und erfolgreicher Kommunikation bei 10% liegt.
Ist der Aktor hingegen nicht erreichbar bringen die 13 Sendeversuche den DC auf 99%. Sicherlich spielen da noch die Retries mit, die der Controller unternimmt wenn die Gegenstelle nicht erreichbar ist. Ich bin mir aber ziemlich sicher dass das in früheren Versionen so nicht der Fall war.
Auch dass der DC nicht mehr zurück geht so lange der Aktor nicht erreichbar bleibt macht das ganze System ziemlich unbrauchbar.

[Black]

als das mit dem DC kann ich so nicht beobachten.... am Spielsystem verhält sich das unauffällig.

Black

[User 17410]

Hallo Herr Maus! Haben sie dieses Problem vernommen?

viewtopic.php?f=65&t=46300&start=90#p463863

Im Moment scheint es so, als würden sie es ignorieren.

[jmaus]

Hallo Herr Maus! Haben sie dieses Problem vernommen?

viewtopic.php?f=65&t=46300&start=90#p463863

Im Moment scheint es so, als würden sie es ignorieren.

Ich ignoriere gar nichts, ich bin nur beschäftigt. Aber ja, das habe ich gesehen. Das sind allerdings alles Probleme die vornehmlich wohl eQ3 lösen müsste da dies auch auf einer reinen CCU3 so passieren wird.

[LibertyX]

Das der DC nach oben geht, wenn du einen Aktor mehrfach hintereinander ansteuerst (egal ob erreichbar oder nicht) ist normal und muss auch so sein.

Dann erkläre bitte auch warum der DC nach 13x senden und erfolgreicher Kommunikation bei 10% liegt.
Ist der Aktor hingegen nicht erreichbar bringen die 13 Sendeversuche den DC auf 99%. Sicherlich spielen da noch die Retries mit, die der Controller unternimmt wenn die Gegenstelle nicht erreichbar ist. Ich bin mir aber ziemlich sicher dass das in früheren Versionen so nicht der Fall war.
Auch dass der DC nicht mehr zurück geht so lange der Aktor nicht erreichbar bleibt macht das ganze System ziemlich unbrauchbar.

Du hast dir deine Frage selbst beantwortet, ist ein Empfänger nicht erreichbar, versucht die Zentrale je Schaltvorgang diesen mehrfach zu erreichen, dass können bis zu 10 Versuche sein.

Der DC geht wieder zurück, sobald die Sendeversuche aufhören, allerdings nach gesetzlicher Vorgabe erst nach 1 Std.

[MathiasZ]

Ist es eigentlich möglich die Alarmmeldung bein einem DC von 98 % herunterzuregeln?
Wenn ein DC von 98 % erreicht ist, ist es meist zu spät, um Gegenmaßnahmen einzuleiten.
Ich fände, eine Alarmmelung bei 70 - 75 % wäre besser.
Gruß,
Mathias

[jmaus]

Ist es eigentlich möglich die Alarmmeldung bein einem DC von 98 % herunterzuregeln?

Nein, das ist momentan nicht möglich. Ist halt auch eine ALARM Meldung und keine Warnung. Wenn du was anderes haben willst bau dir ein WebUI Programm das regelmäßig den DC selbst überprüft und dann dir eine Warnung schickt.