HB-UNI-Sensor1 - Neuauflage

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Rieeg
Beiträge: 34
Registriert: 20.11.2020, 16:23
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 1 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Rieeg » 07.07.2021, 21:27

Danke Tom, ich werde mich mal daran versuchen.

TomMajor
Beiträge: 1788
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 08.07.2021, 20:58

Rieeg hat geschrieben:
07.07.2021, 21:27
Danke Tom, ich werde mich mal daran versuchen.
ja gerne, bei Problemen einfach hier fragen.
Wenn es nur um eine Diff.Temp geht und es nicht super dringend ist kann wahrsch. auch mein Bsp. dafür abwandeln, sollte kein großer Aufwand sein.
Viele Grüße,
Tom

Benutzeravatar
Baxxy
Beiträge: 10604
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 594 Mal
Danksagung erhalten: 2173 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Baxxy » 09.07.2021, 15:52

Kurze Rückmeldung noch zu meinen 3 UNI-Sensoren...

Seit dem fixieren der I2C-Adressen mittels Lötbrücken und einer 3 tägigen Eichphase sind 2 nun an an ihren angedachten Einsatzorten montiert und tun dort klaglos ihren Dienst.
  • Nr.1 überwacht den langen dunklen Flur und wird zur Steuerung der Ambiente-Beleuchtung herangezogen
  • Nr.2 überwacht den Wohnbereich und wird zur Steuerung der Ambiente-Beleuchtung sowie zur Lüftungsempfehlungs-Berechnung herangezogen
  • Nr.3 darf irgendwann an die Ostsee ziehen um das Ferienhäuschen zu überwachen

Vielen Dank nochmal... :)
Grüße
Baxxy

Irgendwann werde ich noch einen für den Außenbereich fitmachen...

Matsch
Beiträge: 5345
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Matsch » 09.07.2021, 16:24

Baxxy hat geschrieben:
09.07.2021, 15:52
... tun dort klaglos ihren Dienst.
Alles andere hätte mich auch gewundert.

Lokverführer
Beiträge: 39
Registriert: 30.01.2019, 11:33
Hat sich bedankt: 9 Mal
Danksagung erhalten: 1 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Lokverführer » 12.07.2021, 14:55

Hallo zusammen,

ich möchte letztendlich einen Sensor bauen der aus einem DS18X20, VEML6075 und BH1750 besteht.

Für jemanden wie mich, der Null Ahnung vom Programmieren hat, ist das schon ein hartes Stück Arbeit :x

Der Unisensor 6 müsste allerdings doch bereits mein Bedürfnis erfüllen, da dort der VEML6075 schon drin ist. Muss ich außer einer Anpassung der .ino und der Device_Example.h noch weitere Änderungen vornehmen?

In der Raspberrymatic taucht das Feld [UV-Index] auf, der Wert ist immer 0.00, während im seriellen Monitor ein UVI von z.B. 10 sichtbar ist.
Muss ich etwa auch bei Verwendung der bereits bestehenden Beispiele eine xml auf der Raspberrymatic ändern?

Device_Example.h

Code: Alles auswählen

// Definition von Device ID und Device Serial
// Bei mehreren Geräten des gleichen Typs (HB-UNI-Sensor1) muss Device ID und Device Serial unterschiedlich sein!
#define cDEVICE_ID      { 0xA5, 0xA5, 0x16 }
#define cDEVICE_SERIAL  "UNISENS016"

#define SENSOR_DS18X20    // ONEWIRE_PIN define weiter unten muss zur HW passen! DS18X20_COUNT muss definiert sein!
//#define SENSOR_BME280       // BME280 Library (finitespace) verwendet I2C Addr. 0x76, für 0x77 die Library anpassen!
//#define SENSOR_BMP180
//#define SENSOR_MAX44009   // MAX44009_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_TSL2561    // TSL2561_ADDR define weiter unten muss zur HW passen!
#define SENSOR_BH1750     // BH1750_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_SHT31      // SHT31_ADDR define weiter unten muss zur HW passen!
//#define SENSOR_SHT21
//#define SENSOR_SHT10      // SHT10_DATAPIN / SHT10_CLKPIN define weiter unten muss zur HW passen!
//#define SENSOR_DIGINPUT   // DIGINPUT_PIN define weiter unten muss zur HW passen!
//#define SENSOR_VEML6070
#define SENSOR_VEML6075
Sensor1.ino

Code: Alles auswählen

const struct DeviceInfo PROGMEM devinfo = {
    cDEVICE_ID,        // Device ID
    cDEVICE_SERIAL,    // Device Serial
    { 0xF1, 0x16 },    // Device Model HB-UNI-Sensor1

TomMajor
Beiträge: 1788
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 13.07.2021, 00:22

Hi Lokverführer,

das sehe ich auch so, ganz ohne Programmiererfahrung ist das eigentlich Wahnsinn. :wink:

Die Sensoren2..6 sind nur als Beispiele und Anregung gedacht, um eigenen Sensoren zu gestalten.
In deinem Fall sieht es mir so aus das der Sensor1 Sketch die erst vor ein paar Wochen hinzugefügte neue Payload Abs.Luftfeuchte und Taupunkt hat, aber das xml für Sensor6 nicht, dafür aber den UV-Index. Das passt nicht ohne Änderungen zusammen.

WeatherEventMsg init() muss so umgestaltet werden dass die erzeugte payload zum xml passt. Ich könnte dir evtl. die nächsten Tage ein Bsp. für deinen Fall machen.
Viele Grüße,
Tom

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von papa » 13.07.2021, 08:57

Für FHEM habe ich ja eine generische Sensoranbindung gemacht, da wird dann in der Zentrale eingestellt, wie die Daten in der Nachricht zu interpretieren sind - siehe hier https://forum.fhem.de/index.php/topic,5 ... #msg804110

Könnte man nicht auch in der CCU irgendwie ein Programm machen, welches dann nur noch das Format kriegt und die Werte aus der Nachricht in das Gerät schreibt ? Das würde das Problem mit den 1000 verschiedenen Wünschen an Sensorkombinationen lösen.
Anfragen zur AskSin++ werden nur im Forum beantwortet

jp112sdl
Beiträge: 12072
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 846 Mal
Danksagung erhalten: 2138 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 13.07.2021, 09:12

papa hat geschrieben:
13.07.2021, 08:57
Könnte man nicht auch in der CCU irgendwie ein Programm machen, welches dann nur noch das Format kriegt und die Werte aus der Nachricht in das Gerät schreibt ? Das würde das Problem mit den 1000 verschiedenen Wünschen an Sensorkombinationen lösen.
Das ist so ein "Luxusproblem".

Natürlich könnte man einen Kanal nehmen, als Float definieren, ihm einen Wertebereich von -1000000.00 bis +1000000.00 geben und die Einheit weg lassen.
Dann ist es egal, welcher Sensor da welchen Wert reinschreibt.

Aber dann steht halt in der CCU WebUI nicht mehr schön "UV-Index", oder "Temperatur" oder "Luftfeuchtigkeit", sondern nur noch der generische Name.
Und es ist auch bei der Auswahl in Programmen bzw. Filterung in Skripten (DPByHSSDP) "nimm nur Kanäle vom Typ TEMPERATURE" hinderlich.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Lokverführer
Beiträge: 39
Registriert: 30.01.2019, 11:33
Hat sich bedankt: 9 Mal
Danksagung erhalten: 1 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von Lokverführer » 13.07.2021, 21:15

TomMajor hat geschrieben:
13.07.2021, 00:22
In deinem Fall sieht es mir so aus das der Sensor1 Sketch die erst vor ein paar Wochen hinzugefügte neue Payload Abs.Luftfeuchte und Taupunkt hat, aber das xml für Sensor6 nicht, dafür aber den UV-Index. Das passt nicht ohne Änderungen zusammen.

WeatherEventMsg init() muss so umgestaltet werden dass die erzeugte payload zum xml passt. Ich könnte dir evtl. die nächsten Tage ein Bsp. für deinen Fall machen.
Hallo Tom,

das wäre toll! :D

Könnte man eigentlich auch die (Roh-)Werte für UVA und UVB an die CCU übertragen?

TomMajor
Beiträge: 1788
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 14.07.2021, 19:17

Lokverführer hat geschrieben:
13.07.2021, 21:15
TomMajor hat geschrieben:
13.07.2021, 00:22
In deinem Fall sieht es mir so aus das der Sensor1 Sketch die erst vor ein paar Wochen hinzugefügte neue Payload Abs.Luftfeuchte und Taupunkt hat, aber das xml für Sensor6 nicht, dafür aber den UV-Index. Das passt nicht ohne Änderungen zusammen.

WeatherEventMsg init() muss so umgestaltet werden dass die erzeugte payload zum xml passt. Ich könnte dir evtl. die nächsten Tage ein Bsp. für deinen Fall machen.
Hallo Tom,

das wäre toll! :D

Könnte man eigentlich auch die (Roh-)Werte für UVA und UVB an die CCU übertragen?
ja, wenn man einmal die payload und das xml dazu verstanden hat kann man fast alles machen.. :)
ich mache dir erstmal (vorauss. WE) eine Version des Sensor6 mit deiner Kombo zum Testen. Falls das geht reden wir später über die Rohwerte.
Viele Grüße,
Tom

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“