HB-UNI-Sensor1 - Neuauflage

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

Moderator: Co-Administratoren

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 10.07.2020, 21:01

Nur rein informativ ein paar Anregungen von mir:
Den Datenpunkt "Wassertemperatur" (oder Sauna etc.) zu nennen ist, auf das gesamte CCU-System gesehen, vielleicht ungünstig.
Ein Problem ist dabei vielleicht, dass der Datenpunkt nicht in Diagrammen verwendet werden kann.
Aber vielleicht möchtest du mal in einem Skript alle Geräte mit Temperaturen erfassen. (...DPByHssDP("TEMPERATURE");) - da fällt "Wassertemperatur" dann raus.

Aus meiner Sicht wäre es "richtiger/konformer", je Datenpunkt einen separaten Kanal zu benutzen.
Es können mehrere Kanäle auch vom selben Typ sein (bspw. 3x TEMPERATURE).
Du gibst dann in der WebUI dem Kanal deinen gewünschten Namen, wie es bei anderen Geräten üblich ist.
Dann muss auch nicht für jedes Gerät irgendwas an den XML angepasst werden.

Die Werte können trotzdem in einem einzelnen Telegramm übertragen werden. Die Zuordnung zu den Kanälen erfolgt über das "channel_field".
Praktiziert wird sowas bspw. beim Temperaturdifferenzsensor HM-WDS30-OT2
https://github.com/AskSinPP/asksinpp.de ... 30_ot2.xml
https://github.com/jp112sdl/Beispiel_As ... S18B20.ino

VG,
Jérôme ☕️

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

magnum1795
Beiträge: 246
Registriert: 13.05.2020, 17:56
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 39 Mal
Danksagung erhalten: 21 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von magnum1795 » 11.07.2020, 10:59

@jp112sdl

danke dir für die Info. Aber ich kann ja nicht Schritt 5 vor Schritt 2 machen. Bin erstmal froh das nun erstmal die Wassertemperatur mit angezeigt wird. Hatte dies zwar schon alles am laufen, sogar mit Display 4x20, aber eben alles mit einen ESP8266. Da ich nun nach und nach weg möchte und alles unter einen "Hut" haben möchte, bin ich bei Homatic gelandet und ersetze nun nach und nach meine ESP8266 durch die AskSinPP Projekte.

Aber du hast natürlich vollkommen Recht, man sollte es schon von Anfang an gleich "Richtig" machen. Muss mich dazu aber erst noch mehr einlesen und beschäftigen. Werde es aber auf jeden Fall in Angriff nehmen. Meine Device ist ja, "Geht nicht, gibt es nicht. Unmögliches wird sofort gemacht, Wunder dauern etwas länger" :P

So, nun zum Max44009. Habe nachgelötet und jetzt wird er auch erkannt. Ist eigentlich schon eine "Sauerei" wenn man als Kunde dann noch selbst Hand anlegen muss damit es geht. Da hat wohl irgendjemand geschludert. Aber Ende gut, Alles gut. :lol:

AskSin++ V4.1.6 (Jul 11 2020 10:32:16)
DS18x20 found: 28AE2A7F3A190192
BME280 found
MAX44009 found
Sensor setup done
Serial: UNISENS002
Clock SYSCLOCK
Address Space: 32 - 79
CC init1
CC Version: 04
- ready
tmBattery Voltage: 3322
Battery set low: 21
Battery set crit: 19
Config Freq: 0x21659A
Config Changed: List0
ledMode: 1
lowBatLimit: 21
Battery set low: 21
transmitDevTryMax: 6
updCycle: 60
altitude: 0
BME280 Temperature x10 : 256
BME280 Pressure x10 : 10008
BME280 PressureNN x10 : 10008
BME280 Humidity : 46
DS18x20 Temperature : 254
MAX44009 Brightness x100: 301824
<- 17 01 84 70 A5A502 000000 01 00 27 18 2E 00 04 9B 00 00 FE 0C FA 00 - 1236
Dateianhänge
uni sensor 1-5.jpg

ivo-int
Beiträge: 300
Registriert: 13.04.2020, 08:55
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 37 Mal
Danksagung erhalten: 16 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von ivo-int » 11.07.2020, 11:48

Hallo magnum1795

Ich klinke mich hier auch einmal ein da es bei mir ebenfalls ein Thema ist.
magnum1795 hat geschrieben:
10.07.2020, 20:42
Danke. Wenn ich das soweit Richtig verstanden habe mit den zweiten Sensor, könnte ich ihn z.B. HB-UNI-Sensor2 und als ID dann 0xFB01 nehmen ?

Wegen den Max44009 werde ich mal probieren nachzulöten. Habe leider momentan keinen anderen mehr hier, nur einen GY-302 BH170. Sollte ja eigentlich auch gehen dann. Aber erst mal nachlöten und schauen was passiert.
Nach vielen Versuchen mit dem Addon von Jerome und Tom musste ich feststellen dass es etwas komplexer ist. Aber eventuell liege ich ja hier falsch.

Ich habe ein neues Frimware, Install und Uninstall XML z.B. mit der Bezeichnung "HB-UNI-Sensor2" erstellt. Auch das Device Modell habe ich auf einen freien Bereich gelegt.

Meine Vermutung ist das die Homematic nicht weis dass es ein Gerät mit "HB-UNI-Sensor2" mit der entsprechenden Device Modell gibt. Ich denke das es mit dem Addon angelegt wird.

Wie Tom schreibt: Mit dem Hochziehen der Firmware können neue Geräte angelegt werden. Das funktioniert perfekt.

Eventuell kann Tom einen Tipp geben wie man dieses Thema am besten angeht um ein eigenes Device zu erstellen?

Gruss Ivo
_______________________________________________________________________________________________________
Raspberrymatic auf einem Raspi 4 4GB (HB-RF-USB-2) mit 2 LAN Gateways,
42 RF Geräte, 4 IP Geräte und 21 Cuxd Geräte, 24 RF Eigenbau Geräte
hm_pdetect, E-Mail, XML-API, JB HB Devices, HB-TM-Devices-AddOn, CUx-Daemon, CCU-Historian auf einem separaten Raspi

magnum1795
Beiträge: 246
Registriert: 13.05.2020, 17:56
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 39 Mal
Danksagung erhalten: 21 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von magnum1795 » 11.07.2020, 12:21

@ ivo-int

zwei "Dumme" ein Gedanke. Auch ich habe es so versucht wie du. Neues Devicemodel angelegt (FB01) und die entsprechenden Dateien angepasst. Wie du auch, habe ich es HB-Uni-Sensor2 benannt und auch beide Dateien (install und uninstall...) angelegt mit der neuen Devicemodell Nr. FB01. dann noch zusätzlich im custom_firmwareordner eine zweite Datei (hb-uni-sensor2.xml) angelegt. CCU3 komplett neugestartet und nach Reboot wollte ich dann den HB-UNI-Sensor2 dann anlernen, wird aber nicht erkannt und kann/konnte ihn nicht anlernen. Im Sketch hatte ich auch die Firmware ID von 0xF1 und 0x01 auf eben 0xFB und 0x01 abgeändert, sowie auch in der Device_Example.h angepasst. Gebracht hat es leider nichts.

Da es anscheinden noch mehr Interessenten gibt, wäre es nicht schlecht wenn hier mal jemand etwas ausführlicher erklärt wie man ein neues Devicemodel anlegt und dieses dann auch angelernt werden kann.


@ jerome
Das mit dem Diagrammen und Co. ist vorerst erstmal uninteressant und nutze ich nicht.
natürlich werde ich dann später versuchen es so umzusetzten wie du oben beschrieben hast. Aber dafür langt es momentan noch nicht im "Oberstübchen" und muss mich noch viel mehr einlesen etc. Mir würde es momentan erstmal langen wenn ich eben das Zweite (neue) Device mit eben den anderen namen anlegen könnte und das klappen würde.

@ ivo-int
und ja, wenn Tom einen Tipp geben kann wie man dieses Thema am besten angeht um ein eigenes Device zu erstellen , wäre das nicht schlecht. man lernt nie aus.

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 11.07.2020, 13:04

Ja mit neuem Device Model muss auch im install script das Gerät in der DEVDB.tcl und WebUI.js bekannt gemacht werden.

VG,
Jérôme ☕️

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

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

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 11.07.2020, 13:37

Übrigens, das was Jerome oben über das Kanalkonzept schreibt hatte harvey für den HB-UNI-Sensor1 mal extensiv umgesetzt, müsste hier im Forum noch irgendwo zu finden sein.

habe noch mal kurz über das 2. Gerät nachgedacht. Wie Jerome schreibt, nur ein zweites neues Device Model reicht leider nicht, es müssen ja auch die anderen patches und copies gemacht werden
https://github.com/TomMajor/SmartHome/b ... ni-sensor1

Übrigens habe ich hier einiges an Know-How und Fallstricken für AddOn-Entwicklung dokumentiert:
https://github.com/TomMajor/SmartHome/t ... duced/Docs

ich vermute eine schnelle Lösung wäre über die Firmware Version. Bin aber nicht sicher welche Fallstricke dort noch lauern werden. Kompatibilität bei Updates meines AddOn ist dann wahrsch. eingeschränkt.
Am Besten eine kleinen Versionstring nehmen der bei mir nie kommen wird weil ich schon auf 13 bin:

Code: Alles auswählen

<parameter index="9.0" size="1.0" cond_op="E" const_value="0x01" />
Viele Grüße,
Tom

magnum1795
Beiträge: 246
Registriert: 13.05.2020, 17:56
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 39 Mal
Danksagung erhalten: 21 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von magnum1795 » 11.07.2020, 14:01

jp112sdl hat geschrieben:
11.07.2020, 13:04
Ja mit neuem Device Model muss auch im install script das Gerät in der DEVDB.tcl und WebUI.js bekannt gemacht werden.
ich habe ja die/das install_hb-uni-sensor1 und uninstall_hb-uni-sensor1 kopiert, dann umbenannt in install_hb-uni-sensor2 und dort drin dann folgendes geändert. Ebenso dann bei uninstall geändert.

Original:

#------------------------------------------------------------------------------
# in der WebUI angezeigter Gerätetyp, muss identisch sein mit dem Firmware-XML-Tag: <type name="HB-UNI-Sensor1" id="HB-UNI-Sensor1">
DEVICE="HB-UNI-Sensor1"
# in der WebUI angezeigte Gerätebeschreibung
DEVICE_DESC="Universalsensor1 (Wetterdaten)"
# Name der Piktogramme, bestehend aus xx.png bzw. xx_thumb.png
DEVICE_IMG=hb-uni-sensor1.png
DEVICE_THUMB=hb-uni-sensor1_thumb.png
FIRMWARE_FILE=/firmware/rftypes/hb-uni-sensor1*.xml

meine geänderten Werte: (Fett)

#------------------------------------------------------------------------------
# in der WebUI angezeigter Gerätetyp, muss identisch sein mit dem Firmware-XML-Tag: <type name="HB-UNI-Sensor2" id="HB-UNI-Sensor2">
DEVICE="HB-UNI-Sensor2"
# in der WebUI angezeigte Gerätebeschreibung
DEVICE_DESC="Universalsensor1 (Wetterdaten)"
# Name der Piktogramme, bestehend aus xx.png bzw. xx_thumb.png
DEVICE_IMG=hb-uni-sensor1.png
DEVICE_THUMB=hb-uni-sensor1_thumb.png
FIRMWARE_FILE=/firmware/rftypes/hb-uni-sensor2*.xml

und dann noch in der hb-uni-sensor2.xml in customized_firmware.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<device version="2" rx_modes="CONFIG,WAKEUP,LAZY_CONFIG" cyclic_timeout="45000">
<supported_types>
<type name="HB-UNI-Sensor2" id="HB-UNI-Sensor2" updatable="true">
<parameter index="9.0" size="1.0" cond_op="E" const_value="0x13" />
<parameter index="10.0" size="2.0" const_value="0xFB01" />
</type>

und im Sketch

const struct DeviceInfo PROGMEM devinfo = {
cDEVICE_ID, // Device ID
cDEVICE_SERIAL, // Device Serial
{ 0xFB, 0x01 }, // Device Model
// Firmware Version
// die CCU Addon xml Datei ist mit der Zeile <parameter index="9.0" size="1.0" cond_op="E" const_value="0x13" />
// fest an diese Firmware Version gebunden! cond_op: E Equal, GE Greater or Equal
// bei Änderungen von Payload, message layout, Datenpunkt-Typen usw. muss die Version an beiden Stellen hochgezogen werden!
0x13,

und der Device_Example.h steht das hier und habe ich so belassen.

//---------------------------------------------------------
// 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, 0x01 }
#define cDEVICE_SERIAL "UNISENS001"

Da es ja nun ein "neues" Device ist, sollte es doch so gehen oder muss man hier auch etwas ändern?

Was müsste denn noch alles geändert werden damit man das "neue" Device dann auch anlernen kann?

#------------------------------------------------------------------------------
# Edit DEVDB.tcl
devdescrFile="/www/config/devdescr/DEVDB.tcl"
devdescrSearch="array[[:space:]]*set[[:space:]]*DEV_PATHS[[:space:]]*{"

devdescrInsert="$DEVICE {{50 \/config\/img\/devices\/50\/$DEVICE_THUMB} {250 \/config\/img\/devices\/250\/$DEVICE_IMG}} "

if [ -z "`cat $devdescrFile | grep \"$DEVICE\"`" ]; then
sed -i "s/\($devdescrSearch\)/\1$devdescrInsert/g" $devdescrFile
fi

#------------------------------------------------------------------------------
# Edit webui.js
webuiFile="/www/webui/webui.js"
webuiSearch="DEV_HIGHLIGHT[[:space:]]*=[[:space:]]*new Array();"

webuiInsert="\n"
webuiInsert="${webuiInsert}DEV_HIGHLIGHT['$DEVICE'] = new Object();\n"
webuiInsert="${webuiInsert}DEV_LIST.push('$DEVICE');\n"
webuiInsert="${webuiInsert}DEV_DESCRIPTION['$DEVICE']='$DEVICE_DESC';\n"
webuiInsert="${webuiInsert}DEV_PATHS['$DEVICE'] = new Object();\n"
webuiInsert="${webuiInsert}DEV_PATHS['$DEVICE']['50'] = '\/config\/img\/devices\/50\/$DEVICE_THUMB';\n"
webuiInsert="${webuiInsert}DEV_PATHS['$DEVICE']['250'] = '\/config\/img\/devices\/250\/$DEVICE_IMG';"

if [ -z "`cat $webuiFile | grep \"$DEVICE\"`" ]; then
sed -i "s/\($webuiSearch\)/\1$webuiInsert/g" $webuiFile
fi


Kannst das bitte etwas genauer Beschreiben für "Normalsterbliche" Nichtprogrammierer? Vielen dank schon mal

magnum1795
Beiträge: 246
Registriert: 13.05.2020, 17:56
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 39 Mal
Danksagung erhalten: 21 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von magnum1795 » 11.07.2020, 14:30

@ TomMajor

unsere Post haben sich wahrscheinlich gerade überschnitten. habe ich zu spät gesehen.

Du meinst also das ich in der in der hb-uni-sensor2.xml in customized_firmware.xml

den eintrag
<parameter index="9.0" size="1.0" cond_op="E" const_value="0x13" /> durch eben diesen


<parameter index="9.0" size="1.0" cond_op="E" const_value="0x01" />

ersetzen soll und dann sollte auch (nach Neustart der CCU) der "neue" Sensor HB-UNI-SENSOR2 angelernt werden ?

Werde ich dann mal probieren.

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

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 12.07.2020, 00:13

Leg einen neuen hb-uni-sensor1_fw0x01.xml an, mache dort den ...const_value="0x01" Eintrag und im Arduino sketch natürlich auch die Firmware 01 setzen.
dann diese xml unter /customized_firmware ablegen und RM neustarten. Vielleicht geht es so auf Anhieb, vlt. nicht.
Neue xml für RM zu entwickeln ist viel Trial and Error nach meinen Erfahrungen.
Viele Grüße,
Tom

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 12.07.2020, 00:25

magnum1795 hat geschrieben:
11.07.2020, 14:01
Kannst das bitte etwas genauer Beschreiben für "Normalsterbliche" Nichtprogrammierer? Vielen dank schon mal
Es gibt halt auch so viele Fallstricke, die man pauschal nicht alle einfach so runterschreiben kann.
Zumal es auch wirklich umfangreich ist.
Da tippt man sich die Finger wund
TomMajor hat geschrieben:
12.07.2020, 00:13
Neue xml für RM zu entwickeln ist viel Trial and Error nach meinen Erfahrungen.
Ich finde WebUI-Anpassungen für spezielle Geräte viel schlimmer.
Wenn ich da an den kürzlich hinzugefügten HB-OU-MOT-FAN denke...
Bildschirmfoto 2020-07-12 um 00.24.22.png
Da fällt die XML gar nicht weiter auf :D

VG,
Jérôme ☕️

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

Antworten

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