HB-UNI-Sensor - VEML6070 Support?

[spaceduck518]

Hallo Tom,

wäre es möglich den VEML6070 (UV Sensor) in den UNI-Sensor zu integrieren? Der VEML6070 wird wie die anderen Sensoren auch per I2C angesprochen. Wäre eine ideale Ergänzung zum MAX44009. ;-)

Jan

[TomMajor]

Das wäre prinzipiell kein Problem, kannst du mir einen solchen Sensor sponsern? Ich brauche von jedem unterstützten Sensor ein Exemplar in der Schublade um ggf. nach SW-Anpassungen die Sensorfunktionen erneut zu verifizieren.

[spaceduck518]

Das ist kein Problem, ich werde Dir den Sensor sponsern. Ich kontaktiere Dich am besten per PN im Homematic Forum zwecks Abwicklung.

[TomMajor]

Status: Waiting for VEML6070...

[TomMajor]

Status: sensor received

[TomMajor]

Hallo Jan,

habe den VELM6070 kurz mit einem Testsketch betrieben, ansprechbar war er, UV konnte ich wegen Dunkelheit nicht testen.

Bevor ich den in den UniSensor integriere sollten wir noch ein paar Fragen klären. Ich integriere den wie gesagt gerne, mir fehlt im Moment aber die Zeit für Recherchen zum Thema UV, vielleicht kannst du das übernehmen. Meine Fragen:

• Wir wollen schon den richtigen UV Index haben und nicht nur den Rohwert vom Sensor? Die Adafruit Lib gibt den Rohwert aus.

• Jerome hat hier diese Formel für den Index, wie kommt er auf die Werte? https://github.com/pa-pa/AskSinPP/blob/master/sensors/Veml6070.h#L74 _uvindex = (_uvvalue < (12 * 187)) ? (_uvvalue + 1) / 187 : 11;

• Gibt es eine native HomeMatic Größe/Variablentyp die den UV Index abbildet oder wie soll das in HM gemapped werden?

Ein paar links zum Thema:

https://learn.adafruit.com/adafruit-veml6070-uv-light-sensor-breakout/overview https://forum.mysensors.org/topic/6952/veml6070-and-veml6075-uv-sensors https://www.vishay.com/docs/84310/designingveml6070.pdf

[jp112sdl]

Jerome hat hier diese Formel für den Index, wie kommt er auf die Werte?

Ich nutze die kürzeste INTEGRATION_TIME IT=1T und habe die Berechnung "Rohwert zu UV Index" gemäß der Tabelle auf Seite 5 des Datenblatts vorgenommen:

Demnach entspricht die Differenz zwischen 2 UV Index-Werten 187 UVI.

Gibt es eine native HomeMatic Größe/Variablentyp die den UV Index abbildet

Nein, die gibt es nicht

oder wie soll das in HM gemapped werden?

Das muss @spaceduck518 entscheiden 😄

[TomMajor]

@jp112sdl ok, verstehe, danke für den Hinweis. Warum das +1? Value 560 ergibt damit UV3, strenggenommen wäre das aber noch 2. Nur so als Frage, der Fehler dadurch ist sicherlich zu vernachlässigen da wir über einen 2000 range sprechen. Wahrscheinlich Linearisierungsfehler die man mit einem einfachem /187 nicht alle abdecken kann.

Bleibt die Frage nach der HM Integration.

[jp112sdl]

Wahrscheinlich Linearisierungsfehler die man mit einem einfachem /187 nicht alle abdecken kann.

Ja genau irgendsowas war da. z.B. 1121/187 = (int)5 daher noch +1, um 6 zu erhalten

[TomMajor]

ok, passt schon, auf 1,2 digits wird es beim Rohwert nicht ankommen.

Da wir gerade dabei sind, ein Designfehler im HB-UNI-Sen-WEA fällt mir auf: Du hast den template Param INTEGRATION_TIME eingeführt, der vom user prinzipiell im sketch änderbar wäre. Wenn er dies aber tut passt deine UV index Kalkulation mit /187 für Zeiten ungleich 1T nicht mehr. Solange der user den sketch diesbezüglich nicht ändert ist aber alles gut, wollte es nur erwähnen da er mir gerade auffällt.

[jp112sdl]

Du hast den template Param INTEGRATION_TIME eingeführt, der vom user prinzipiell im sketch änderbar wäre.

Ja das stimmt. Die Berechnung müsste mal noch für die anderen INTEGRATION_TIME erweitert werden

[TomMajor]

Wahrscheinlich reicht ein einfaches 2 oder 4 für den 187 Wert (bei 2T und 4T).

[jp112sdl]

Wahrscheinlich reicht ein einfaches 2 oder 4 für den 187 Wert (bei 2T und 4T).

Genau. Hab ich mal mit eingebaut

[spaceduck518]

Gibt es eine native HomeMatic Größe/Variablentyp die den UV Index abbildet oder wie soll das in HM gemapped werden?

Ich überlege die ganze Zeit was ich zu der Frage beitragen kann... Leider kann ich dazu als "Nicht-Softwareentwickler" wenig bis nichts beisteuern. Da Jerome den VEML bereits in seiner Wetterstation verbaut hat sollte doch da was existieren?!

[TomMajor]

Die Sensor Messung hätte ich schnell im AVR sketch integriert. Ich überlege nur noch wie man das am Einfachsten und ohne Auswirkungen auf andere user ins AddOn bringt. Meine Gedanken so weit: Ich führe im Unisensor z.B. 2 Byte extra custom payload einmalig ein, mit entspr. Firmware Versionserhöhung in sketch und xml. Die extra Bytes können von usern jederzeit für andere Zwecke belegt werden.

Und auf CCU/RM Seite muss der user dann im xml nach Bedarf anpassen, für UVI z.B.

<parameter id="UVINDEX" operations="read,event"> ... und <parameter type="integer" index="24.0" size="0.4" param="UVINDEX"/>

Das würde ich für UVI beispielhaft bereitstellen.

So muss nicht jedesmal die Firmware Version, payload usw hochgezogen werden, was Auswirkungen auf alle user hat und was ich auf keinen Fall für jeden neuen user/sensor Wunsch machen kann und will.

@jp112sdl was meinst du?

[jp112sdl]

2 Byte extra custom payload

Nur für den Fall,

Die extra Bytes können von usern jederzeit für andere Zwecke belegt werden.

dass die kompletten 2 Bytes ausgenutzt würden: ▶️ <parameter type="integer" index="24.0" size="2.0" param="UVINDEX"/>

Und auf CCU/RM Seite muss der user dann im xml nach Bedarf anpassen, für UVI z.B.

Dann müsstest du wohl noch eine "Custom XML" Option berücksichtigen. Denn wenn der User die originalen Files bearbeitet, würden sie nach einer Neuinstallation des Addons wieder mit der Quelldatei überschrieben werden.

Weiterhin würde dann zwar noch eine saubere Übersetzung in der WebUI fehlen, aber ich denke das ist ok. Dann steht dort halt [UVINDEX] statt z.B. UV-Index. Es sei denn, meine Addon Version ist parallel auch noch installiert - dann kommt diese Übersetzung ja mit. Oder du baust noch eine eigene Übersetzung mit ein.

[TomMajor]

Moin Jerome,

das mit size 2.0 ist klar, war nur ein Bsp., ich würde wie gesagt ein custom UVI xml für den UniSensor1 bereitstellen wenn es dieses Konzept wird. Übersetzung ebenso klar, ich denke mit [UVINDEX] kann man erst mal leben.

Das das Addon bei Neuinstallation die customized firmware überschreiben wird ohne extra Vorkehrungen auch klar, das ist der Punkt wo ich konzeptmäßig noch zögere. Hatte auch schon deine copy customized firmware commands in init|start gesehen.

Ist da eigentlich die korrekte Funktion bei 1) user backup einspielen, 2) CCU/RM Firmware Update, 3) neue AddOn Version einspielen, immer die Gleiche? D.h. wenn durch 1) .. 3) die $ADDON_DIR wieder da bzw. upgedatet ist ist auch $CUSTOMIZED_FIRMWARE_DIR wieder da und in init|start wird immer die customized firmware kopiert? Mir ist nicht klar ob der user noch einen extra Neustart bei customized firmwares braucht oder ob wirklich der eine copy in init|start reicht um sofort die neue customized firmware zu haben - für alle 3 Fälle?

Else Zweig ist für spätere user updates der customized firmware nehme ich an.

[jp112sdl]

Ist da eigentlich die korrekte Funktion bei 1) user backup einspielen, 2) CCU/RM Firmware Update, 3) neue AddOn Version einspielen, immer die Gleiche?

Ja schon. Beim 2) FW Update ist jedenfalls garantiert alles im read-only Space überschrieben worden. Bei 1) und 3) könnte es sein, dass bereits eine frühere Version installiert war und somit schon webui.js etc. modifiziert wurden. Wobei 1) auf einem blanken System als auch bei einem laufenden System durchgeführt werden könnte.

Bei der Installation kopiere ich den Inhalt aus $CUSTOMIZED_FIRMWARE_DIR wieder in $ADDON_DIR/firmware/rftypes, weil ja durch die Installation erstmal meine XML Files wieder ausgeliefert werden. Also zuerst wird die Werks-XML nach $ADDON_DIR/firmware/rftypes kopiert. Anschließend werden die vom User angelegten nach $ADDON_DIR/firmware/rftypes, wobei dann die Werks-XML überschrieben werden.

Legt der User im laufenden System eine Customized XML an, kommt der else-Zweig zum Tragen. Ich vergleiche die XML Dateien aus dem $CUSTOMIZED_FIRMWARE_DIR mit denen aus $ADDON_DIR/firmware/rftypes. Sind sie unterschiedlich wird kopiert und rfd neu gestartet; sind sie gleich passiert nix. Somit wird auch nicht bei jedem Start der CCU die Datei kopiert. Einzig den rfd-Restart muss ich dort noch abfangen. Das darf nicht im 'init' gemacht werden, weil der Dienst da noch nicht läuft und auch der multimacd noch nicht läuft.

[TomMajor]

@jp112sdl Danke für die Erläuterungen, so in etwa hatte ich mir das gedacht, war nur nicht sicher ob das mit Customized XMLs gleichermaßen für die Fälle 1)..3) funktioniert.

Legt der User im laufenden System eine Customized XML an, kommt der else-Zweig zum Tragen. Ich vergleiche die XML Dateien aus dem $CUSTOMIZED_FIRMWARE_DIR mit denen aus $ADDON_DIR/firmware/rftypes.

Dafür muss der user nach seinem Kopieren manuell Neustarten, korrekt? weil Check ist ja im init|start Zweig.

Anschließend werden die vom User angelegten nach $ADDON_DIR/firmware/rftypes kopiert, wobei dann die Werks-XML überschrieben werden.

Geht das gut ohne den -f param beim cp? Stichwort default overwrite behavior of cp https://unix.stackexchange.com/a/477414 Konnte keine einfache ja/nein Antwort darin finden :crying_cat_face:

[jp112sdl]

Dafür muss der user nach seinem Kopieren manuell Neustarten, korrekt? weil Check ist ja im init|start Zweig.

Jap.

Geht das gut ohne den -f param beim cp?

Es gab noch keine negativen Rückmeldungen. Schaue ich mir auch gern noch mal an, sobald es mal wieder 🌧 😄

[TomMajor]

ok, klingt gut, ich werde das customized firmware Konzept sowie die custom payload die nächsten Tage in den UniSensor1 einbauen. Bei der Gelegenheit erhöhe ich auch gleich die MAX44009 Auflösung aus der anderen issue https://github.com/TomMajor/SmartHome/issues/14

[jp112sdl]

Also das mit der CCU FW ausgelieferte cp überschreibt ohne Nachfrage auch ohne -f.

[TomMajor]

ok gut zu wissen. Ich lese von beiden Varianten, abhängig vom System, wovon genau abhängig habe ich nicht gefunden.

[jp112sdl]

wovon genau abhängig habe ich nicht gefunden.

Ja, mit verschiedenen Distributionen werden oftmals verschiedene Versionen/Stände der GNU Tools ausgeliefert.

patch ist auch so ein Kandidat. Deimos hatte , als er dabei war, mein Addon für Debmatic als Paket zu portieren, den Vorschlag, mit der Option --dry-run zu prüfen, ob ein Patch schon applied war. Diese Option hat das BusyBox-patch der CCU Firmware jedoch gar nicht einbaut. In Raspbian/Armbian und eigentlich allen anderen mir bekannten Linux-Distribution ist sie aber verfügbar.

[TomMajor]

Die Feature 'Benutzerspezifischen Sensordaten' und VEML6070 support sind jetzt drin. Beschreibung: https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1#benutzerspezifischen-sensordaten

Danke an @jp112sdl für die Ideen mit der custom firmware.

[TomMajor]

VEML6070 support hinzugefügt.

[TomMajor]

VEML6075 support hinzugefügt, Danke an spaceduck518 für den Sensor.