Tropfbewässerung: Sketche kombinieren

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

Moderator: Co-Administratoren

harvey
Beiträge: 136
Registriert: 01.12.2013, 13:19
Danksagung erhalten: 3 Mal

Re: Tropfbewässerung: Sketche kombinieren

Beitrag von harvey » 03.05.2020, 00:28

Hi, vielleicht ist es so, dass IRGENDEIN Text so transportiert wird?!?

Jedenfalls habe ich eher zufällig gesehen, dass wenn der Sensor (genau genommen der Dummy) den Wert sendet, der im XML als NO_SENSOR steht, genau dieser Text im iobroker auftaucht.

Schwierig wird das mit experimentieren, da iobroker NICHT mit den Firmware-basierten XMLs umgehen kann. Siehe letztes Update UNI-Sens-LEV-US, wo für Firmware 1.1 die CM Abstand als zusätzlicher Wert in der CCU korrekt angezeigt werden, aber nicht im iobroker.

Der Wert darf sogar unter/oberhalb von min/max liegen, muss aber zum Type des Wertes passen (uint/int).

Deshalb hatte ich für mich mal UNPLAUSIBLE Werte als Dummy genommen und die als NO_SENSOR bezeichnet. Dann kann man sich zumindest im iobroker nicht mehr vertun, ob tatsächlich ein Sensor angeschlossen ist. Schlecht ist z.B. 0°C als Temperatur-Dummy, das gibt es im Winter ja manchmal :-)
Daher auch die 2000000 bei Lux als NO_SENSOR, da 0 (zero) Lux ja ein zusässiger Wert ist. Ähnlich für Druck, da geht 0 HPa, da dieser Wert ja physikalisch nie auftreten kann als athmospherischer Druck.

Wie gesagt, die CCU reagiert anscheinend garnicht darauf, leider. Wäre doch super, wenn bei NO_SENSOR das Anzeigefeld ausgeblendet würde ... ist aber nicht so :-(

cu
Harvey
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte

harvey
Beiträge: 136
Registriert: 01.12.2013, 13:19
Danksagung erhalten: 3 Mal

Re: Tropfbewässerung: Sketche kombinieren

Beitrag von harvey » 03.05.2020, 00:34

Hi Tom, habe mir gerade die von Dir erwähnte Zeile angesehen.

Genauso ist es. Da die Humidity=0 wohl? niemals auftaucht könnte das richtig sein. Falsch ist allerdings der Wertebereich 1-99, hast Du ja aber auch schon korrigiert.

Eventuell ist es sogar beesser NO_SENSOR auf z.B. 200 zu setzen, das ist physikalische kompletter Unfug, dann ist der gesammte Bereich von 0...100 zulässig. Schaden tut es wohl in der CCU nicht :-)
cu
Harvey
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte

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

Re: Tropfbewässerung: Sketche kombinieren

Beitrag von TomMajor » 03.05.2020, 01:48

ja, stimme zu, im Fall des ioBrokers könnte es vielleicht auch IRGENDEIN Text sein.
ich weiß, ioBroker hat diese Aktualisierungsprobleme bei Änderungen im xml. Wenn Löschen der meta nicht hilft, was glaub ich immer hilft ist dieses neue Datenfeld manuell im ioBroker beim Gerät hinzufügen, habe ich dunkel in Erinnerung aus irgendeinem Thread hier.

wenn wir die Sache weiterspinnen und uns noch mal diese Zeile anschauen

Code: Alles auswählen

<special_value id="NO_SENSOR" value="0" />
Jerome schreibt das NO_SENSOR in OCCU, eq3-XMLs und Binärdateien nicht auftaucht.
Eine Möglichkeit wäre noch das es mit Code special_value id eine oder mehrere andere special IDs (nicht NO_SENSOR) gibt, die Sachen in der CCU steuern könnten, z.B. auch die Nicht-Anzeige usw. Nur so ein Gedanke.
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: Tropfbewässerung: Sketche kombinieren

Beitrag von jp112sdl » 03.05.2020, 07:34

TomMajor hat geschrieben:
03.05.2020, 01:48
mit Code special_value id eine oder mehrere andere special IDs (nicht NO_SENSOR) gibt, die Sachen in der CCU steuern könnten, z.B. auch die Nicht-Anzeige usw.
Kann es sein, dass special_value nur für die benutzerfreundliche Auswahl in der WebUI ist?
https://github.com/eq-3/occu/blob/14b4d ... #L586-L587

z.B.: Dimmer:
Die rf_d.xml hat ein

Code: Alles auswählen

<special_value id="OLD_LEVEL" value="1.005" />
Der Benutzer kann in der WebUI beim Einrichten einer DV wählen: [SHORT_ON_LEVEL: "Letzer Dimmwert"].
Wird nun in der Verknüpfung "Letzter Dimmwert" bei kurzem Tastendruck ausgewählt, wird der Wert "1.005" als Dimmwert verwendet.

Oder Winmatic, da kann man die Öffnung auf 0...100% (es wird 0.0-1.0 zum Gerät gesendet) bzw. "LOCKED" (es wird dann -0.005 zum Gerät gesendet) einstellen.


Die special_value sind also dafür da, um vordefinierte Werte zum Gerät zu senden.

Die in den eQ-3 XMLs verwendeten möglichen special_value id="..." sind überschaubar.

Code: Alles auswählen

ACT_LEVEL
LOCKED
NOT_USED
NO_MODIFICATION
OLD_LEVEL
PERMANENT
VENT_OPEN [nur HM-CC-TC]
VENT_CLOSED [nur HM-CC-TC]


P.S.: Es gibt auch special_parameter, um nur bestimmte Geräteparameter, je nach Auswahl, anzuzeigen 8)
Derzeit nur im EM-8 verwendet.

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: Tropfbewässerung: Sketche kombinieren

Beitrag von TomMajor » 03.05.2020, 16:41

Moin Jerome,

ok, das sind interessante Hinweise das special_value für die Richtung zum Gerät ist, dann ist es einfach für den ehemals (homebrew) angedachten Zweck damit Anzeigefelder in der CCU zu steuern nicht geeignet, legen wir das Thema besser wieder ad acta :)

Kurze andere Frage, kann ich eigentlich 2x den gleichen Typ in einem channel verwenden, ist das eq3 like oder gibt es da irgendwo Probleme?
z.B.

Code: Alles auswählen

...
        <parameter id="VALVE_STATE" operations="read,event">
          <logical type="integer" min="0" max="1" />
          <physical type="integer" interface="command" value_id="VALVE_STATE" no_init="true">
            <event frame="WEATHER_EVENT" />
          </physical>
        </parameter>
...
    <frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="1" type="0x70">
...
      <parameter type="integer" index="18.0" size="0.1" param="VALVE_STATE" />
      <parameter type="integer" index="18.1" size="0.1" param="VALVE_STATE" />

bekomme ich so 2 unabhängige "Ventilpositionen" in der CCU?
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: Tropfbewässerung: Sketche kombinieren

Beitrag von jp112sdl » 03.05.2020, 17:16

Nein, du fütterst damit den einen

Code: Alles auswählen

<parameter id="VALVE_STATE" operations="read,event">
aus 2 Quellen.

Wenn du die ID "VALVE_STATE" mehrfach verwenden willst, geht das nur über einzelne Kanäle.
Du kannst aber auch mit 1 Telegramm und dem channel_field mit 1 Telegramm-Kanal alle Gerätekanäle übertragen.

Wie z.B. beim HB-UNI-Sen-TEMP-DS18B20, wo auch alle Temperaturen mit der ID "TEMPERATURE" einen eigenen Kanal in der CCU darstellen; physisch aber nur 1 Kanal übertragen. Im Telegramm steckt dann drin, welcher Wert zu welchem Kanal gehören.

https://github.com/jp112sdl/HB-UNI-Sen- ... S18B20.ino
https://github.com/jp112sdl/JP-HB-Devic ... n-temp.xml

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: Tropfbewässerung: Sketche kombinieren

Beitrag von TomMajor » 03.05.2020, 19:40

Hmm, hatte schon vermutet das dies nicht so einfach geht da ja dann auch die Eindeutigkeit des Signals/Bezeichnungspfad fehlt (bei 2x VALVE_STATE im channel).

Das mit den channel_field behalte ich mal im Hinterkopf, aber vorher schaue ich mir noch mal die anderen möglichen Typen an, wo genau standen noch mal diese Typen wie TEMPERATURE, AIR_PRESSURE, VALVE_STATE , das war irgendein binary, oder?

Ich bräuchte nur einen weiteren Typ um einen Fehlerzustand zu kennzeichnen beim HB-UNI-Sensor-Heizung, dafür reichen 2 mögliche Werte, also boolean, kann aber auch mehr sein.
Viele Grüße,
Tom

harvey
Beiträge: 136
Registriert: 01.12.2013, 13:19
Danksagung erhalten: 3 Mal

Re: Tropfbewässerung: Sketche kombinieren

Beitrag von harvey » 03.05.2020, 20:03

Hi, nur ne kurze Anmerkung (sonst bin ich ja eher länger:_)
im Telegram (so nenne ich mal das /die Datenpakt(e) vom Senor zur CCU*) können Werte an festen Positionen stehen, dann aber immer an genau der Position, leer lassen oder überspringen geht nicht.
Das geht super, wenn immer z.B. 4 Werte gesendet werden, unabhängig von Änderungen ode ob sie existieren (dann dummy -Value, wird aber gesendet!).
Oder man kann dem Feld eine ID(field_id) geben mit Bitmaske. Das passt wunderbar zu einer variablen Anzahl an gleichen (gleich großen, gleich benamten) Werten.
Das passt wunderbar zu nfach Temperatursensoren. Eigentlich könnte der Sketch selbst feststellen, welche Sensoren geändert sind und nur genau diese senden, Reihenfolge und Anzahl ist egal, da über field_index mit Bitmaske jeder Wert wieder genau zu einem Ergebnis in der Darstellung führt.
Wenn man die Änderung der Werte (bzw. die NICHT-Änderung) überwacht kann man nur die jeweils geänderten Werte senden und sich damit im 8-fach Temperatursensor möglicherweise das Senden von zweimal vier Temperaturwerten reduzieren, wenn etwa nur drei Temperaturen geändert sind (Funkhygiene).
Ein wenig verwirrend ist der Begriff channel, er beschreibt manchmal den Sendechannel, also etwa ein Wetttertelegramm. Dann können aus den Felder dieses einen Telegrams wieder Anzeige-"Channel" werden. Diese sind dann die Unternummern :1 :2 :3 ... des Sensors und können getrent und unabhängig auf "Sichtbar" geschaltet oder weggeschaltet werden. Ausserdem kann man sie in der GUI mit eigenem Namen versehen, statt achtmal "Temperatur" also "Speicher oben, Speicher Mitte, Speicher unten, Zulauf, Rücklauf" und so. In einem einzigen Anzeige-"Channel" sind die Namen ja fix über die XML verdrahtet, die einzelnen Elemente auch nicht mehr "unsichtbar" zu machen.
Für mich extrem hilfreich ist das Studium von Jeromes XML-Dateien, da findet sich eigentlich alles (Wettersendor/8-Fach-Temperatursensor, ...)
SUPER wichtig zu lesen! Auch wenn verstehen schwer fällt, insbesonders Mehrsprachigkeit, Hilfetexte, Bilder und und und .

Schönen Sonntag noch,,bleibt gesund!
cu
Harvey
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte

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

Re: Tropfbewässerung: Sketche kombinieren

Beitrag von jp112sdl » 03.05.2020, 20:11

Das mit der Binary war die HMIPServer.jar, als wir damals herausfinden wollten, welche Datentypen in Diagrammen verwendet werden können.
Aber ich seh auch grad, dass die Typen in /www/webui/js/lang/en/translate.lang.diagram.js auch stehen (diagramValueTypeXXXXXX).

Ich hab mal versucht, alle Datentypen aus den XMLs rauszufischen
xmllint --format /firmware/rftypes/*.xml|grep "operations=\"read,event\"" | awk -F "id=" '{print $2}' | awk -F " " '{print $1}' | sort | uniq

Code: Alles auswählen

"ACTUAL_HUMIDITY"
"ACTUAL_TEMPERATURE"
"ADJUSTING_COMMAND"
"ADJUSTING_DATA"
"AIR_PRESSURE"
"BATTERY_STATE"
"BOOST_STATE"
"BOOST_TIME"
"BOOT"
"BRIGHTNESS"
"COMMUNICATION_REPORTING"
"CONFIG_PENDING"
"CONTROL_MODE"
"COUNTERREADING1"
"COUNTERREADING10"
"COUNTERREADING2"
"COUNTERREADING3"
"COUNTERREADING4"
"COUNTERREADING5"
"COUNTERREADING6"
"COUNTERREADING7"
"COUNTERREADING8"
"COUNTERREADING9"
"CURRENT"
"DECISION_VALUE"
"DEVICE_IN_BOOTLOADER"
"DIRECTION"
"DIRECTION_SLATS"
"DUTYCYCLE"
"ENERGY_COUNTER"
"ERROR"
"ERROR_ALARM_TEST"
"ERROR_BATTERY"
"ERROR_M1"
"ERROR_M2"
"ERROR_M3"
"ERROR_OVERHEAT"
"ERROR_OVERLOAD"
"ERROR_POWER"
"ERROR_REDUCED"
"ERROR_SABOTAGE"
"ERROR_SMOKE_CHAMBER"
"ERR_DETECT_EIA485_SERVICE"
"ERR_TTCU_INTERNAL_TEST"
"ERR_TTCU_LOCK_ROLLERS_SHORTED"
"ERR_TTCU_MAGNET_ERROR"
"ERR_TTCU_POWER_ONTIME_EXCEEDED"
"ERR_TTCU_SENSOR_STRIP_DISCONNECTED"
"ERR_TTCU_SENSOR_STRIP_SHORTED"
"ERR_TTCU_STOP_AFTER_10_CLOSING_TRIES"
"ERR_TTCU_TURN_TILT_ACT_ALLOY_MOSFET"
"ERR_TTCU_TURN_TILT_ACT_ASYNCHRON"
"ERR_TTCU_TURN_TILT_ACT_BLOCKED"
"ERR_TTCU_TURN_TILT_ACT_CONTACT_PROBLEM"
"ERR_TTCU_TURN_TILT_ACT_NO_SPEED_SIGNAL"
"ERR_TTCU_TURN_TILT_ACT_OVERCURRENT"
"ERR_TTCU_TURN_TILT_ACT_SHORTED"
"ERR_TTCU_WRONG_VOLTAGE_POLARITY"
"ERR_TTM_INTERNAL"
"ERR_TTM_OVERVOLT"
"ERR_TTM_UNDERVOLT"
"ERR_WINDOW_NOT_FOUND"
"ERR_WIN_STAY_IN_INITIAL_OPERATION"
"FAULT_REPORTING"
"FILLING_LEVEL"
"FREE_TO_USE"
"FREQUENCY"
"GAS_ENERGY_COUNTER"
"GAS_POWER"
"HUMIDITY"
"IEC_ENERGY_COUNTER"
"IEC_POWER"
"LEVEL"
"LEVEL_REAL"
"LOWBAT"
"LOWBAT_REPORTING"
"LOWBAT_SENSOR"
"LUX"
"MOTION"
"POWER"
"RAINING"
"RAIN_COUNTER"
"RSSI"
"RSSI_DEVICE"
"RSSI_PEER"
"STATE"
"STATE_UNCERTAIN"
"STATUS"
"SUNSHINEDURATION"
"TEMPERATURE"
"TIPTRONIC_STATE"
"UNREACH"
"UPDATE_PENDING"
"VALVE_STATE"
"VOLTAGE"
"WINDOW_OPEN_REPORTING"
"WINDOW_STATE"
"WINDOW_TYPE"
"WIND_DIRECTION"
"WIND_DIRECTION_RANGE"
"WIND_SPEED"
"WIN_RELEASE"
"WORKING"
"WORKING_SLATS"
Wenn du nur BOOL brauchst, schau mal in die https://github.com/AskSinPP/asksinpp.de ... _8_bit.xml

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: Tropfbewässerung: Sketche kombinieren

Beitrag von TomMajor » 03.05.2020, 23:35

Danke dir, Jerome, ich schau mir das mal morgen in Ruhe an.
Wenn ich noch eine spezielle Frage dazu habe frag ich dann besser direkt um nicht diesen thread hier zu sehr zuzumüllen mit OT. :)
Viele Grüße,
Tom

Antworten

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