RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 4738
Registriert: 17.02.2015, 14:45
Wohnort: Dresden
Kontaktdaten:

RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von jmaus » 22.06.2019, 23:15

Hallo Zusammen,

da sich ein neuer Beitrag für jede neue RaspberryMatic Version bewährt hat (damit man darüber diskutieren kann), hier die Eröffnung eines neues Beitrages zu der heute von mir releasten 3.45.7.20190622 Version (Änderungen siehe viewtopic.php?f=65&t=26917&start=30#p514443).

Bitte in diesem Thread erste Erfahrungen/Hinweise, etc. zu dieser Version (und den neuesten Änderungen darin) diskutieren oder einfach auch nur bestätigen das alles reibungslos funktioniert.

Viel Spass!

Hinweis:
Wie auch bei vorherigen Releases möchte ich auch bei diesem gerne wieder darum bitten bei Gefallen über eine mögliche finanzielle Unterstützung/Spende für das RaspberryMatic nachzudenken. Wenn dem Einen oder Anderen dieser Release gefallen sollte, so würde ich mich natürlich über zahlreiche (auch gerne erneute) Spenden via PayPal oder auch Sachspenden freuen. Für PayPal-Spenden (die meine Motivation an RaspberryMatic weiterhin zu arbeiten wirklich sehr heben) bitte diesen Link nutzen.
RaspberryMatic 3.47.10.20190713 @ TinkerS mit ~160 HomeMatic Geräten + ioBroker – GitHubPayPalTwitter

Hütte
Beiträge: 198
Registriert: 08.02.2017, 11:08

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von Hütte » 23.06.2019, 00:59

Hallo Jens,

Vielen Dank für deine unermüdliche Arbeit an diesem Projekt.

Ich habe da aber noch eine kleine Anmerkung zu deinen Realease-Notes.

Wenn da schon beschrieben wird, dass bestehende Funktionen/Funktionalitäten, wie die State() oder SunAzimuth()/SunElevation()/SunsetTime()/SunriseTime() um neue Parameter erweitert wurden, dann ist es auch sicher sehr sinnvoll, mit anzugeben, wie dann der Aufruf der Funktionen mit den neuen Parametern auszusehen hat.

Bei State() in Scripten gibt es nun zwei optionale Parameter. Der Wert für die Verzögerung in Millisekunden ist selbsterklärend - muss ein Integer-Wert sein. Aber welche Werte sind für den zweiten Parameter erlaubt, wie müssen sie sie im Aufruf innerhalb des Scriptes konkret aussehen und kann auch die Angabe der Verzögerung in Millisekunden fehlen?

Und bei SunAzimuth()/SunElevation()/SunsetTime()/SunriseTime() haben wir da schon einmal einen gavierenden Unterschied zwischen den beiden Gruppen SunAzimuth()/SunElevation() und SunsetTime()/SunriseTime(). OK. Bei SunAzimuth und SunElevation bekomme ich wohl den berechneten Sonnenstand zur übergegeben Uhrzeit zurück. Aber wie muss dann der optionale Parameter übergeben werden?

Und was ist der neue optional Parameter für SunsetTime()/SunriseTime()? Ist das ein Datum? Aktuell erwarte ich beim Aufruf der Funktionen die Zeit für Sonnenaufgang bzw. Sonnenuntergang des aktuellen Tages - abhängig von lokalen Standort, den ich im System hinterlegt habe. Was kann hier also als optionaler Parameter übergeben werden? Ein Datum? Oder Positionskoordinaten? Und wie muss dass Format aussehen. Und gibt es da Unterschiede bei den Ausgaben der Funktion, wenn ich sie mit oder ohne optionalen Parameter aufrufe?

Wenn solche Informationen gleich in die Realease-Notes mit einfließen würden, dann werden mit Sicherheit weniger gleich- oder ähnlichlautende Anfragen hier im Forum auftauchen, der "Frustlevel" bei so manchem Nutzer sinken und sowohl Akzeptanz als auch aktive Nutzung der neuen Funktionalitäten steigen.

Sorry. Aber als Mathematiker und Entwickler für Schnittstellen bin ich gerade an dieser Stelle immer sehr ganz genau. Gerade wenn es sich um "zentrale" Funktionen handelt, sollte immer gut beschrieben sein, welche Parameter zu übergeben sind, in welchem Format sie angeliefert werden müssen und was als Ausgabe in welchem Typ/Format zurück gegeben wird.

Gruß,
Hütte

Xel66
Beiträge: 5384
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von Xel66 » 23.06.2019, 05:28

Hütte hat geschrieben:
23.06.2019, 00:59
Aber welche Werte sind für den zweiten Parameter erlaubt, wie müssen sie sie im Aufruf innerhalb des Scriptes konkret aussehen und kann auch die Angabe der Verzögerung in Millisekunden fehlen?
Die entsprechenden Parameter habe ich im zugehörigen GitHub-issue #262 gefunden. Dort schreibt Jens, dass es für eine sofortige Ausführung keinen Unterschied zur bisherige Syntax gibt.

Code: Alles auswählen

boolean result = dom.GetObject("BidCos-RF.012345678:4.SET_TEMPERATURE").State(9);
Für eine Verzögerung um beispielsweise 500ms ist der State-Parameter um die Anzahl der Millisekunden zu erweitern.

Code: Alles auswählen

boolean result = dom.GetObject("BidCos-RF.012345678:4.SET_TEMPERATURE").State(9, 500);
Um laufende Verzögerungen nicht zu löschen oder zu retriggern, wird der Parameter einfach um ein "false" erweitert. Ich gehe davon aus, dass das komplementäre "true" ebenfalls funktioniert. Da dieses aber das Standardverhalten ist, dürfte es optional (aka überflüssig) sein. Letztendlich ist es nach jeinem Verständnis nur die Scriptoption der Checkbox "Retriggern" aus dem WebUI.

Code: Alles auswählen

boolean result = dom.GetObject("BidCos-RF.012345678:4.SET_TEMPERATURE").State(9, 500, false);
Hütte hat geschrieben:
23.06.2019, 00:59
Und bei SunAzimuth()/SunElevation()/SunsetTime()/SunriseTime() haben wir da schon einmal einen gavierenden Unterschied zwischen den beiden Gruppen SunAzimuth()/SunElevation() und SunsetTime()/SunriseTime().
Nun, ja. Hierzu habe ich auch etwas im GitMemory gefunden, aber noch keinen so rechten Anwendungszweck.
Starting with ReGaHss R1.00.0388.0208 it will be possible to specify a time variable as an optional parameter to system.SunAltitude() and system.SunAzimuth() so that you can then use the following command to get the altitude of the sun @ 12:00:

Code: Alles auswählen

var alt = system.SunAltitude(@12:00@);
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. Alternativ könnte ich mir zukünftig eine WebUI-Konfigurationsmöglichkeit in den Astroparametern des Zeitmoduls vorstellen. Eigentlich gehören derartige Parameter dort hin, aber die Nutzungsmöglichkeit per Script ist ein Anfang. Dieses könnte man sinnvoll in eine Beschattungslösung einbinden (z.B. die Elevation: Sonne ist hinterm Nachbarn aus verschwunden - Beschattung kann beendet werden). Ein Problem bei der Elevationsberechnung ist allerdings, dass die Sonne pro Tag zwei Mal die gleiche Elevation hat (außer im Zenit natürlich).

Für eine zeitpunktgenaue azimutale Steuerung von Beschattungslösungen wären solche Zeitpunkte auch gut nutzbar. Mit den neuen Variablen konnte man das auch erreichen, aber eben nur mit einem zyklischen Scriptlauf und nachfolgendem Vergleich des Ergebnisses. Bis auf einer einfachere Handhabung ist das aber kein Fortschritt gegenüber dem bisherigen Sonnenstandsscript. Das muss auch zyklisch laufen.
Hütte hat geschrieben:
23.06.2019, 00:59
Und was ist der neue optional Parameter für SunsetTime()/SunriseTime()?
Dazu habe ich noch nichts gefunden. Die originalen Systemparameter ließen sich bisher ja auch schon verwenden. Ich benutze dieses um einen vorgezogenen Sonnenuntergang in einen CUxD-Timer zu schreiben. Vielleich lässt sich hier ja ein Offset vergeben? Ansonsten macht eine zusätzliche Zeitangabe keinen Sinn. Dazu suche ich noch.

Gruß Xel66
---------------------------------------------------------------------------------
335 Kanäle in 103 Geräten und 113 CUxD-Kanäle in 23 CUxD-Geräten:
233 Programme, 189 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 3.45.5.20190330
---------------------------------------------------------------------------------

MathiasZ
Beiträge: 1189
Registriert: 29.03.2015, 09:54
Wohnort: München

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von MathiasZ » 23.06.2019, 06:46

so wie ich Jens kenne, wird dieses Update wieder erste Sahne sein.
Nur werde ich dieses update mal überspringen, weil ich in meinem wohlverdienten Urlaub bin.
Von Fern-Updates halte ich nichts, weil es könnte doch das eine oder andere Problem auftauchen......

Nun bleibt eine Frage , die absolut unwichtig ist, offen:
Wenn Jens das Addon IObroker schreiben will, dann frage ich mich, ob es nicht sinnvoll wäre die Raspberrymatic auch auf auf den Rock64 bzw den Rock PI zu migrieren. Beide Einplatinen-Computer haben 4GB-RAM.

Für mich würde das sowieso nicht infrage kommen, da ich lieber die Raspberrymatic und IObroker auf verschiedene Systeme laufen lasse. Sollte einer der beiden Mini-PC's abschmieren, dann habe ich wenigstens noch eine Minimal-Installation am laufen.
RaspberryMatic mit der neuesten Firmware auf Raspberry PI3 B+ und der HB-RF-USB, CuxD Highcharts und viele Aktoren und Sensoren. Es kommen hin und wieder mal neue dazu. Nun versuche ich mich mit ein paar Xiaomi Smarthome-Aktoren und dem Xiaomi Gateway 2. Diese sollen am IObroker, Rock64, 4/32GB über Zigbee-Stick angebunden werden. Die Anwesenheitskennung läuft zuverlässig über IObroker und Radar2 mit G-Tags.

Benutzeravatar
AndiN
Beiträge: 2434
Registriert: 10.06.2015, 08:54
Wohnort: Hennef

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von AndiN » 23.06.2019, 10:16

Hallo,

Update eingespielt. Bis dato keine Auffälligkeiten. Komischerweise ging bei meinem Backup-Raspberry mit der Version 3.45.5.29190330 nach Aktivierung die Systemsteuerung in keinem Browser mehr (weisse Seite). Komisch, weil der Raspberry bis zum Mai lief und ich die Systemsteuerung auch immer genutzt hatte. Shit-happens.

Habe dann die Karte mit dem Win32DiskImager und der aktuellen FW neu geflasht und dann lief alles ohne Probleme.

Danke an Jens und Mitentwickler.

Andi
Greenhorn

Letzter Reboot: 13.07.19 - FW Update // Uptime-Rekord: 65 Tage
Systeminfos: Raspberry Firmware: 3.47.10.20190713, 125 Geräte
Addons: Drucken 1.2a - HQ WebUI 2.5.7 - XML-API 1.20 - CUx-Daemon 2.3.3 - E-Mail 1.6.8c - hm_pdetect 1.5 - VPN cloudmatic
System angebunden: 3 Roomba 650 - Sprachausgabe via Home24 Media - Zentrale: Asus TF103 mit Home24 Tablet
- Diverse Links

brinabella
Beiträge: 42
Registriert: 05.01.2015, 12:37

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von brinabella » 23.06.2019, 10:29

Hallo.
Update 3.45.7.20190622 gemacht. Nach Neustart ist der HMIPW-Drap nicht mehr in der Webui.Neu hinzugefügt, neu gestartet wieder weg.Habe das jetzt 3 mal probiert Drap ist nach jedem Neustart wieder weg.Die HmIPW-DRBL4 funktionieren aber trotz Servicmeldungen (Gerätekommunikation gestört ) über Taster und Programme. Die HMIPW-DRS8 schalten nicht mehr(Gerätekommunikation gestört).

MartinBr
Beiträge: 274
Registriert: 25.01.2017, 10:51
Wohnort: Bei Berlin

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von MartinBr » 23.06.2019, 11:25

Hallo,
ich habe gestern das Update zu CUxD 2.3 eingespielt und heute morgen das Update 3.45.7.20190622 installiert.
Ergebis ist, dass alles funktioniert.
Super Ergebnis und vielen Dank an Jens! :D

Gruß und Dank
Martin
RaspberryMatic-3.47.10 auf TinkerBoard S, CUxD 2.33, XML-1.20, ioBroker unter Debian 9, Alexa mit ioBroker, VitoComfort 200

Xel66
Beiträge: 5384
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von Xel66 » 23.06.2019, 11:56

MathiasZ hat geschrieben:
23.06.2019, 06:46
Sollte einer der beiden Mini-PC's abschmieren, dann habe ich wenigstens noch eine Minimal-Installation am laufen.
Abhängig von der Hardwareausstattung kann das einen sehr begrenzten Zweck haben. Ist das Smarthome fast ausschließlich mit Homematic-Komponenten ausgestattet, bringt Dir ein laufender iobroker schon mal für die Automatisierung wenig. Aber auch ich bin ein Freund von getrennten Systemen, wobei ich die Logikebene des Smarthomes nicht auslagern würde (also die Automatisierung im iobroker programmieren), wie es hier im Forum teilweise propagiert wird, denn dann hat man einen ähnlichen Effekt.

Meine Automation läuft auch ohne jegliche Netzwerkkommunikation weiter. Hat also eine zentrale Netzwerkkomponente mal ein Problem, dann läuft das System trotzdem weiter. Wegen der besseren Scriptsprache würde ich ausschließlich verzichtbare Dinge auslagern (Mailversand, Pushdienste, Kommunikation mit externen Diensten).

Betreibt man allerdings ein buntes Sammelsurium unterschiedlichster Hersteller als Gerätepark, macht eine zentrale Verwaltung im iobroker schon Sinn. Aber bis auf Hue gibt es für mich wenig Gründe, mir auch noch andere Hersteller ins Boot zu holen, weil es das System nur unnötig verkompliziert. Ich käme nicht auf die Idee, die Außentemperatur, die ich für meine Heizungssteuerung essenziell benötige, über einen Internetdienst oder Sensor eines anderen inkompatibel Systems über zusätzliche Anbindungen einzubinden. Solche essenziellen Dinge müssen auch autark (im Sinne von "ein System") laufen können, um Direktverknüfungen nutzen zu können und externe, ggf. instabile Kommunikationen vermeiden zu können.

Gruß Xel66

EDIT: Version 3.45.7.20190622 installiert (erstmalig per WebUI) - bis jetzt läufts problemlos --> vielen Dank an alle Beteiligten
Zuletzt geändert von Xel66 am 23.06.2019, 13:05, insgesamt 1-mal geändert.
---------------------------------------------------------------------------------
335 Kanäle in 103 Geräten und 113 CUxD-Kanäle in 23 CUxD-Geräten:
233 Programme, 189 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 3.45.5.20190330
---------------------------------------------------------------------------------

Samhain
Beiträge: 110
Registriert: 30.03.2017, 13:44

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von Samhain » 23.06.2019, 12:02

Update auf Tinker S ohne Fehler

Danke! 8)

Benutzeravatar
jmaus
Beiträge: 4738
Registriert: 17.02.2015, 14:45
Wohnort: Dresden
Kontaktdaten:

Re: RaspberryMatic 3.45.7.20190622 – Erfahrungsberichte

Beitrag von jmaus » 23.06.2019, 12:22

brinabella hat geschrieben:
23.06.2019, 10:29
Update 3.45.7.20190622 gemacht. Nach Neustart ist der HMIPW-Drap nicht mehr in der Webui.Neu hinzugefügt, neu gestartet wieder weg.Habe das jetzt 3 mal probiert Drap ist nach jedem Neustart wieder weg.Die HmIPW-DRBL4 funktionieren aber trotz Servicmeldungen (Gerätekommunikation gestört ) über Taster und Programme. Die HMIPW-DRS8 schalten nicht mehr(Gerätekommunikation gestört).
Das hört nicht nicht gut an. Bitte mal probieren der Datei /bin/checkHmIPdevices.sh die ausführbaren rechte entziehen (chmod) und schauen ob dann nach einem Neustart der DRAP nicht mehr entfernt wird. Wenn ja, dann bitte auf GitHub ein Ticket aufmachen dazu.
RaspberryMatic 3.47.10.20190713 @ TinkerS mit ~160 HomeMatic Geräten + ioBroker – GitHubPayPalTwitter

Gesperrt

Zurück zu „RaspberryMatic“