RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

[Andy61]

Hallo Wissende,

was bedeutet eigentlich die Meldung beim DRAP Status "inaktiv"? Ich kann das Gerät per ping erreichen, es ist im Netz per DHCP. Die Firmware wird angezeigt. Interne Prozesse bei DRI und DRS funktionieren. Kann ich noch etwas zur Kontrolle unternehmen? Gern auch auf der Konsole.

LG

Andreas

[dpomt]

Hallo Dieter und Matthias,

jmaus hat mir hierzu einen Tipp gegeben nachdem er sich meine files angeschaut hat.

Ich habe ein Update zurück auf die 3.41 vom 22.12.18 gemacht, was meiner letzten Version mit dem Backup entspricht.
(allerdings Gerät quasi neu eingerichtet, da ich dann gleichzeitig auf den Asus Tinker S umgestiegen bin)

Einspielen des Backups hat prima funktioniert. Alles wieder wie vorher!

Ein Update auf 3.45 vom 11.05 hat auch funktioniert / Alle Geräte weiterhin vorhanden.

Dann verlief das Update auf 3.45 vom 22.06 schlussendlich auch Problemlos.

Hallo Curo,
jmaus hatte mir heute ähnlichen Tipp gegeben.
Neue SD mit 3.45.7.20190511, Backup von 3.41 eingespielt und dann auf die 3.45.7.20190622 upgedatet.
Alle HMIP Devices wieder da!

Vielen Dank!!

[onkeltommy]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

So weit gehe ich sicher nicht zurück, danach stimmt bei mir im System gar nichts mehr.

@ Jens.....ist da ein erneutes Update geplant ? So macht es eigentich kaum Sinn die aktuelle Version einzuspielen ....

lG Thomas

[darkbrain85]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

So weit gehe ich sicher nicht zurück, danach stimmt bei mir im System gar nichts mehr.

Das lag doch nur daran, dass sein letztes Backup so alt war... oder irre ich?

[jmaus]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

Na klar ist das nur für Betroffene.

[holgerwolf]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

Na klar ist das nur für Betroffene.

Da ich bei einem Update von 2.29.23.20171216 wohl auch in das Problem komme (mir fehlen bei einem direkten Update auf die 3.45.7.20190622 auch alle HM-IP Devices) , zur Sicherheit die Nachfrage, welches Zwischenupdate für mich im Besten ist. Auch die 3.45.7.20190511 ?

Danke und Gruß
Holger

[jmaus]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

Na klar ist das nur für Betroffene.

Da ich bei einem Update von 2.29.23.20171216 wohl auch in das Problem komme (mir fehlen bei einem direkten Update auf die 3.45.7.20190622 auch alle HM-IP Devices) , zur Sicherheit die Nachfrage, welches Zwischenupdate für mich im Besten ist. Auch die 3.45.7.20190511 ?

Das ist eine gute Frage. Deine Version ist doch schon ... RECHT alt.. Ich würde vmdl. erst einmal auf 3.41.x gehen und dann danach auf 3.45.7.20190511 und dann auf die aktuellste.. Aber auch hier gilt: "Probieren geht über studieren"

[Xel66]

Hallo Jens,

könntest Du bitte noch mal was zu den "neuen" Parametern "SunsetTime()/SunriseTime()" schreiben und wie diese sinnvoll zu nutzen sind? Ich habe dazu nicht direkt etwas gefunden. Eine Zeitangabe bei der Berechnung der Zeitpunkte ergibt ja keinen Sinn, denn egal an welchen Zeitpunkt eines Tages diese Werte berechnet werden, bleiben sie für diesen beteeffenden Tag gleich. Oder kann man mit den Parametern durch zusätzliche Angabe einer "Zeit" einen Offset von den berechneten Werten direkt erhalten? Das würde für mich einen Sinn machen.

Dann hatte ich in meinem Post in diesem Thread in einem Satz beiläufig mal eine Anregung hinterlassen. Zitat: "Für die umgekehrte Berechnung eines Zeitpunktes, zu der ein bestimmter Sonnenwinkel erreicht ist, hätte ich eher Verwendung, um diesen Zeitpunkt z.B. in einen CUxD-Timer schreiben zu können. " Wäre so etwas möglich? Ich denke, ein einmaliger Trigger ist ressourcenschonender als eine zyklische Berechnung dieser Werte. Könntest Du Dir vorstellen, dieses in eine zukünftige Version zu integrieren?

Gruß Xel66

[onkeltommy]

Hi.....hoffe, dass das nur ein Workaround für Betroffene ist......

Na klar ist das nur für Betroffene.

Hi Jens...

d.h. "für mich" und andere welche noch nicht upgedated haben.....besser warten ?

lG

T

[jmaus]

könntest Du bitte noch mal was zu den "neuen" Parametern "SunsetTime()/SunriseTime()" schreiben und wie diese sinnvoll zu nutzen sind? Ich habe dazu nicht direkt etwas gefunden. Eine Zeitangabe bei der Berechnung der Zeitpunkte ergibt ja keinen Sinn, denn egal an welchen Zeitpunkt eines Tages diese Werte berechnet werden, bleiben sie für diesen beteeffenden Tag gleich. Oder kann man mit den Parametern durch zusätzliche Angabe einer "Zeit" einen Offset von den berechneten Werten direkt erhalten? Das würde für mich einen Sinn machen.

All diesen Funktionen kannst du mit der neuesten ReGaHss jetzt eine variable vom typ "time". D.h. sowas sollte gehen:

Code: Alles auswählen

var sunset = SunsetTime(@2019-05-01 12:34:56@);

Du hast aber natürlich vollkommen recht das bei Sunset/Sunrise das mit Uhrzeit keinen wirklichen sinn macht. Dort kannst du das dann einfach wie folgt schreiben:

Code: Alles auswählen

var sunset = SunsetTime(@2019-05-01@);

Und schon sollte die Funktion die Sunset zeit für diesen Tag ausspucken.

Dann hatte ich in meinem Post in diesem Thread in einem Satz beiläufig mal eine Anregung hinterlassen. Zitat: "Für die umgekehrte Berechnung eines Zeitpunktes, zu der ein bestimmter Sonnenwinkel erreicht ist, hätte ich eher Verwendung, um diesen Zeitpunkt z.B. in einen CUxD-Timer schreiben zu können. " Wäre so etwas möglich? Ich denke, ein einmaliger Trigger ist ressourcenschonender als eine zyklische Berechnung dieser Werte. Könntest Du Dir vorstellen, dieses in eine zukünftige Version zu integrieren?

Tut mir leid, aber dafür sehe nicht wirklich eine Anwendung die den Aufwand rechtfertigen würde. Da müsste man ja erst einmal dann eine Funktion schreiben die einem die Uhrzeit für einen bestimmten/gewünschten Sonnenwinkel/elevation zurückgibt und diese Funktion habe ich nicht parat. IMHO ist es einfacher in gewissen zyklischen abständen sich den Sonnenstand gebe zu lassen und dann entsprechend zu triggern.