search

TomMajor / SmartHome

Various SmartHome projects, devices, information and examples including AskSinPP usage
86 stars 28 forks source link

Nur eine vorsichtige Anfrage: Erweiterung mit 1/2* Relais Aktoren zur Steuerung mit Sensoren #29

Closed harvey637 closed 4 years ago

harvey637 commented 4 years ago

Hallo Sir Tom, vielen Dank für den Sensor-sketch. Ich verwende ihn mit diversen Anpassungen, u.a. TEMT Helligkeitserkennung und diverse meiner Vorschläge sind ja auch eingeflossen.

Nun habe ich wieder mal eine Idee, etwas inspiriert durch die Heizung :-)

Viele Sensoren dienen zur Steuerung von Verbrauchern, etwa "Lüfter an" bei "Feuchtigkeit > 80%". Eine umfassende Sensorik ist ja in dem Sketch vorhanden.

Aus Platzgründen (und um weniger Module im Einsatz zu haben) wäre ein/zwei Ausgänge zur Relaisansteuerung in dem selben Sketch/Platine eine Erweiterung des Funktionsspektrums des Sketches. Die Elektronik ist simpel, Widerstände, NPNs, LEDs, Relais(anschlüsse), (Freilaufdioden oder SSRs).

Anwendungen etwa: Lüftersteuerung Badezimmer, Temperatursteuerung Aquarium/Weinkeller, Beleuchtung bei Dunkelheit, Abpumpen bei Überflutung, ...

Wo ich mich sehr schwer tue ist:

Testen kann ich gerne, auch mal eine Änderung im Sketch selbst machen oder die rftypes/firmware.xml modifizieren, aber das Gesamtskelett lässt mich am ersten Schritt etwas ratlos.

Ich sehe das so: die XML enthält Sektionen für:

WENN das Thema für Dich interessant ist kann ich gerne mitarbeiten, Zeit habe ich eigentlich. Wenn nicht auch gut, erhöht dann leider die Anzahl der homematic-Module. cu Harvey PS: unterschiedliche xml über Firmwareversion klappt mit iobroker garnicht, und die Sprachanpassung neuer Texte geht auch nur innerhalb homematic-GUI. Es wäre bestimmt nicht schlecht, wenn die HB-Addons auch in den iobroker-rpc-Adapter einfliessen würden, nur so eine Idee...

TomMajor commented 4 years ago

Hey harvey,

long time no see.

Bist du eigentlich jemals auf die Reaktion tldr auf einen deiner Beiträge gestoßen? :crying_cat_face: Nur Spaß :wink:

Ist in etwa eine Luxusversion des HB-UNI-Sensor-Heizung mit Konf. über die WebUI, Sensorauswahl, Aktoren usw.

Prinzipiell finde ich die Idee gut und es gibt bestimmt Bedarf nach solchen Geräten. Ja, man bräuchte wohl extra Kanäle und den letzten Schaltzustand ins EE zu schreiben ist auch keine schlechte Idee.

Die meiste Arbeit machen dafür die Anpassungen im AddOn, xml usw. vermute ich, das macht man nicht mal so nebenbei. Aktuell ist meine Projekt pipeline mehr als voll für den Rest des Jahres. Ich behalte es auf jeden Fall im Hinterkopf da ich die Idee der Erweiterung wie gesagt nicht schlecht finde. Ggf. prüfe ich das mal ernsthaft im nächsten Jahr.

harvey637 commented 4 years ago

Vielen Danke für dir Antwort, Tom, na ja, in der Zwischenzeit z.b. LCD in uni-sensor eingebaut (und das lcd_reversed ist von mir). Und den uni-sensor um Temperaturdifferenz umgebaut. Das allerdings mit neuem DEVICEID und leicht modifizierten channels und xml, ich habe also leidvolle Erfahrungen. Ich werde in jedem Fall selbst versuchen, leider ist die Doku .... wo? Also zusammenbauen aus diversen Beispielen, try und error halt. Step 1 ist sicher der relais-channel mit minimalen xml. Schöne Weihnachtszeit und bis dann, cu Harvey

harvey637 commented 4 years ago

Hallo Sir Tom, vermutlich sind die Anpassungen in dem Heizungs-Sensor gar nicht so groß:

Bye the way: ich denke auch über eine Universalplatine nach:

Wie gesagt, nur ne Idee, aber würde bei mir viele Lochraster ablösen. Nix für mal ganz schnell. Aber in meinem Hinterkopf :-) cu Harvey

harvey637 commented 4 years ago

ok, mit xml geht schon was: oben eingefügt: ` 

  <physical type="integer" interface="config" list="0" index="36" size="2" />
</parameter>
<parameter id="Threshold_max">
  <logical type="integer" min="0" max="65535" default="0" unit="" />
  <physical type="integer" interface="config" list="0" index="38" size="2" />
</parameter>`

diese dann abgefragt: bool threshold_min(uint16_t value) const { return this->writeRegister(0x24, (value >> 8) & 0xff) && this->writeRegister(0x25, value & 0xff); } uint16_t threshold_min() const { return (this->readRegister(0x24, 0) << 8) + this->readRegister(0x25, 0); }

bool threshold_max(uint16_t value) const { return this->writeRegister(0x26, (value >> 8) & 0xff) && this->writeRegister(0x27, value & 0xff); } uint16_t threshold_max() const { return (this->readRegister(0x26, 0) << 8) + this->readRegister(0x27, 0); }

und dem Aufruf mitgegeben: bool bSend = shouldSend(temperature10, digInputState, this->device().getList0().threshold_min(), this->device().getList0().threshold_max() );

und in der Funktion verwendet: bool shouldSend(uint32_t lux, uint8_t& state, uint16_t threshold_min, uint16_t threshold_max) { static bool lastState = false; static uint16_t cycleCounter = MAX_SEND_INTERVAL / MEASURE_INTERVAL; // nach Power-On sofort ein Telegramm senden bool bRet = false; DPRINT(F("Value to test: ")); DDECLN(lux); DPRINT(F("Value min: ")); DDECLN(threshold_min); DPRINT(F("Value max: ")); DDECLN(threshold_max);

if ((!lastState) && (lux >= threshold_max)) {
    lastState = true;
    state     = 1;
    DPRINTLN(F("STATE ON"));
    cycleCounter = 0;
    bRet         = true;
} else if ((lastState) && (lux < threshold_min)) {
    lastState = false;
    state     = 0;
    DPRINTLN(F("STATE OFF"));
    cycleCounter = 0;
    bRet         = true;
}

Nun kommt als nächstes, dass damit ein Relais über NPN aktiviert wird und zusätzlich eine LED (per config abschaltbar, existiert ja schon).

TomMajor commented 4 years ago

Hallo harvey,

das was du über die Universalplatine schreibst, ich habe gerade was ähnliches auf dem Schreibtisch liegen, geht bald public..

Deine Idee sollte auf jeden Fall ein neues Gerät werden da wegen der Aktuatorik das in einigen Fällen einfach kein Sensor für Batteriebetrieb bleiben wird. Außerdem braucht er ein nicht kompatibles AddOn zum UniSensor.

Eventuell bist du z.B. mit einem HB-UNI-SenAct-4-4 als Ausgangspunkt besser bedient da dort schon die Aktorkanäle da sind.

Weitere Berichte über den Projektfortschritt wenns geht nicht in einer github issue hier, das ist der falsche Platz. Du könntest dafür einen thread in HM Forum aufmachen, wäre geeigneter finde ich.

Danke,

wolwin commented 4 years ago

Hi, ich möchte an der Stelle einfach mal dazwischen fragen ... da ich so eine ähnliche Idee umsetzen will. @TomMajor Wir hatten schon mal Kontakt wg. des Gardena 'Sensors' - vielleicht erinnerst Du Dich - da ich Deinen Code zum UniSensor sehr gut finde, habe ich inzwischen neben der Gardena-Platine auch eine eigene Universial-Platine entwickelt. Dort sind mit konventionellem Aufbau (ich kann wie viele andere kein SMD ...) alle mir wichtigen Dinge untergebracht (I2C, 1W, Dein Batteriecheck Variante 2, StepDown <12V, GND schaltbar für I2C und/oder 1W, ...) + 3D-Drucker Files für den Garteneinsatz. Soweit die Hardware ... jetzt zum eigentlichen: ich fände es richtig gut, wenn man über eine 'Konfiguration' die Sensorwerte (oder wie in meinem Fall Schaltzustände an/aus) beliebig auf der Sketchseite setzen könnte - quasi wie ein 'freies' Slot-Inputmodul, dass dann gesendet wird. Auf der HM Seite werden die 'anonymen' Werte dann bezeichnungsmäßig zugewiesen.

Ich weiss jetzt nicht, ob das überhaupt geht - aber vielleicht könnt Ihr mir sagen, ob das so möglich wäre...

Gruss Wolfram

harvey637 commented 4 years ago

Hi @ Tom, so, bin jetzt "ganz schön weit": XML (geänderte DEVICEID 0xF106):

  <supported_types>
    <type name="HB-UNI-Sensor6" id="HB-UNI-Sensor6" updatable="true">
      <parameter index="9.0" size="1.0" cond_op="GE" const_value="0x10" />
      <parameter index="10.0" size="2.0" const_value="0xF106" />
    </type>
  </supported_types>

zusätzliche Konfigurationsfelder:

    <parameter id="Untere Schwelle">
      <logical type="integer" min="0" max="65535" default="0" unit="" />
      <physical type="integer" interface="config" list="0" index="36" size="2" />
    </parameter>
    <parameter id="Obere Schwelle">
      <logical type="integer" min="0" max="65535" default="0" unit="" />
      <physical type="integer" interface="config" list="0" index="38" size="2" />
    </parameter>
    <parameter id="Messungen je Sendeintervall">
      <logical type="integer" min="2" max="255" default="2" unit="" />
      <physical type="integer" interface="config" list="0" index="40" size="1" />
    </parameter>

Frage: sinnvoll könnte ein Feld für die Invertierung des Relais sein (z.B. Alarmierung Tiefkühltruhe). Also ein Bit. Ist da der Teil wie LED_ON das gute Beispiel? So in etwa: 

    <parameter id="Alarmierung invertieren">
      <logical type="option">
        <option id="OFF" default="true" />
        <option id="ON" />
      </logical>
      <physical type="integer" interface="config" list="0" index="41.6" size="0.2" />
      <conversion type="integer_integer_map">
        <value_map device_value="0x00" parameter_value="0" />
        <value_map device_value="0x01" parameter_value="1" />
      </conversion>
    </parameter>

Mir ist die Bedeutung des "Index" und der "Size" nicht ganz klar, beschreibt das das Setzen/rücksetzen des Bit 6 in List0.Position 41 an zwei Bitstellen?????

Ich möchte das erst wissen, bevor ich mit dem Code ins Forum gehe. Denn der Code ist auch "fast fertig" (TM).

harvey637 commented 4 years ago

Hallo @ Tom, (fast) letzter Schritt erledigt (offen nur noch Invertierung), wenn Du GANZ VIEL Zeit haben solltest hier meine Dateien. Sie können - falls es Dir in den Kram passt - GERNE einfach im Forum/github veröffentlicht werden. Wahrscheinlich macht es wenig Sinn, das nochmal getrennt von dem Heizungssensor zu machen, da die Änderungen eigentlich minimal sind. Viel Grüße Harvey Uni-Sensor6.zip

TomMajor commented 4 years ago

@harvey637 Wie gesagt, momentan habe ich leider überhaupt keine Zeit dafür. Mach du gerne was im Forum oder auf deinem github. Sorry, ich kann mich gerade nicht mit Weiterentwicklungen des UniSensors beschäftigen, das hatte ich oben geschrieben.

@wolwin Hey Wolfram, klar erinnere ich mich.

Verstehe aber die Frage nicht vollständig.

Vom Sketch her haben wir ja bereits eine Konfiguration für die versch. Sensoren. Meinst du das universell und konfigurierbar in der Zentrale? So dass nur die konf. Werte zu sehen sind? Das wird schwierig. Eine DeviceID mit einer Firmware Version gehört halt zu einem bestimmten Nachrichtenlayout.

Auch hier würde ich empfehlen die Frage besser im Forum zu stellen. Jerome hat da wesentlich besseren Durchblick.

wolwin commented 4 years ago

@TomMajor 'Meinst du das universell und konfigurierbar in der Zentrale?' - Jein ...

Auf der Sendeseite werden beliebige x Sensorwerte in die Sende-Pipeline geschrieben, die dann auf der CCU-Seite den entsprechenden Feldern / Variablen / Bezeichnungen zugeordnet werden. Beispiel: Temperaturmessungen mit BME280 und DS18B20 werden als zwei Werte gesendet und dann auf der CCU-Seite auch als eigenständige Werte behandelt (über eigene DeviceID) - auf gleichem Weg sollten auch andere Werte, wie z.B. an/aus transportiert werden können. ... wenn ich das so schreibe: eigentlich müssten je eine anpaßbare Parameterliste auf Sende- und Empfangsseite ausreichen ... nur so eine Idee gerade ... Ok, werde mal im Forum bzw. bei Jerome nachfragen ... Danke erst einmal !!

TomMajor commented 4 years ago

ja schon, ich verstehe aber immer noch nicht was das Neue bzw. die Frage daran ist.

Das macht doch @jp112sdl in großem Maßstab schon lange, dass er für seinen vielseitigen Geräte Zoo sein JP Devices AddOn hat wo jedes Gerät mit einem eigenem xml bedient wird. (natürlich sind je nach Gerät noch Anpassungen in weiteren Dateien wie images, language, javascript usw. vorhanden..)

Das hat er auf Sende- und Empfangsseite angepasst, für jedes Gerät (imho). Eventuell meinst du ein Tool was die ganze Arbeit des Anpassens automatisch auf Sketch und xml Seite erledigt?

jp112sdl commented 4 years ago

PS: unterschiedliche xml über Firmwareversion klappt mit iobroker garnicht, und die Sprachanpassung neuer Texte geht auch nur innerhalb homematic-GUI. Es wäre bestimmt nicht schlecht, wenn die HB-Addons auch in den iobroker-rpc-Adapter einfliessen würden, nur so eine Idee...

Bring das mal im ioBroker Forum an. Die sind offen für sowas. https://github.com/ioBroker/ioBroker.hm-rpc#1915-2019-07-01

Was die FW-Version betrifft: Ja, ich glaub die Metadaten werden nur je Gerätetyp angelegt :/

jp112sdl commented 4 years ago

index="41.6" size="0.2" Mir ist die Bedeutung des "Index" und der "Size" nicht ganz klar, beschreibt das das Setzen/rücksetzen des Bit 6 in List0.Position 41 an zwei Bitstellen?????

Nutzt von Index-Byte 41 die Bits 6 und 7 Für deine 2er-Auswahl (ON / OFF) würde 0.1 ausreichen. Ich würde da aber erst gar keine Auswahlliste (Dropdown) nutzen, sondern ein einfaches Ankreuzfeld (Checkbox). Ist sonst mehr Gefummel mit der Maus bzw. auf dem Tablet. Eine Checkbox lässt sich komfortabler auswählen - find ich zumindest. Ist auch wesentlich unspektakulärer in der XML.

Und ich würde immer mit lokalisierten Parameter-IDs arbeiten. Also nicht <parameter id="Alarmierung invertieren"> sondern <parameter id="HB_INVERT_ALARM"> und dann an den entsprechenden Stellen in den WebUI-Files eintragen.

Ist zwar wesentlich aufwendiger, aber "richtiger". Denn bei jedem Aufruf der WebUI wird versucht, eine Übersetzung für "Alarmierung invertieren" zu finden.

Hab ich selbst auch nicht straight von Anfang an gemacht. Es kam aber schon vor, dass englische Bezeichner gewünscht wurden, die mir jemand dann auch zugearbeitet hat. So wird in der WebUI je nach eingestellter Sprache auch der korrekte Text angezeigt. https://github.com/jp112sdl/JP-HB-Devices-addon/blob/master/src/addon/install_hb-uni-sen-wea

Was das Anpassen der Einstellmöglichkeiten für Direktverknüpfungen angeht: Das ist noch mal ein Buch für sich und ich bin viel zu faul das alles aufzuschreiben. Als Ansatz: https://github.com/eq-3/occu/tree/master/WebUI/www/config/easymodes Hier sind die Ansichten angelegt und welches Gerät wie mit welchem anderen Gerät verknüpft werden darf.

Ich mach jetzt schluss hier, sonst bekommt mein Kommentar auch noch ein tldr Flag ^^

harvey637 commented 4 years ago

Hi @ jp112sdl Danke Jerome, ich werde Erläuterungen immer lesen :-) Ja die Mehrsprachlichkeit, habe ich schon gemacht (für Temperatur-Diff auf Toms Basis - ich wollte die HigResVoltage wegen Akku und Solarexperimenten). Klappt eigentlich soweit, aber auch hier ist iobroker etwas strange, und ich wollte eine Baustelle zur Zeit, daher Fokussierung auf "geht erst mal".

Meine Anpassung Heizung kann inzwischen:

Ich werde die Mehrsprachlichkeit noch vorantreiben und ein bischen verfeinern und dann ins Forum stellen. Github und eigene Projektseite oder komplettes Addon, da habe ich nicht vor, noch eine neue Baustelle für mich aufzumachen. Die Änderungen und Anpassungen sind ja auch nicht soooo aufregend, wobei das Ergebnis bei mir vielseitig einsetzbar ist:

PS: der DEVICE_LED_MODE Code mit index="5.6" size "0.2" stand im Original-XML, wahrscheinlich gibt/gab es mal vier verschiedene LED-Modes und nicht nur an/aus. Das hatte mich etwas verwirrt.

jp112sdl commented 4 years ago

PS: der DEVICE_LED_MODE Code mit index="5.6" size "0.2" stand im Original-XML, wahrscheinlich gibt/gab es mal vier verschiedene LED-Modes und nicht nur an/aus. Das hatte mich etwas verwirrt.

Ich hab mal alle XML, die DEVICE_LED_MODE verwenden, durchgeschaut. Keines der Geräte verwendet mehr als die beiden Optionen ON/OFF. Wer weiß, was man sich dabei gedacht hat.

harvey637 commented 4 years ago

Danke für schnelle Hintergrunginfo! Vielleicht bei Duo-LED, an/nur grün/nur rot/aus. Daher auch dropdown anstatt checkbox. Ach wenn EQ doch dokumentiert hätte (bzw. etwas mehr veröffentlicht hätte).

In der Tat ist WEA eine hervorragende, umfangreiche XML, die ich immer wieder versuche zu verstehen. Wobei ich auch noch lernen möchte, einzelne Werte (wenn ohne Sensor z.B: Blitzdetektor, UV-Index) in der GUI nicht sichtbar zu machen. Und dann auch für gleiche Sensoren (Temperatur) jedem Sensor einen eigenen Namen zu geben, das geht ja z.B. beim 8fach Sensor. Also noch viel zu lernen und probieren für mich. cu Harvey

jp112sdl commented 4 years ago

Wobei ich auch noch lernen möchte, einzelne Werte (wenn ohne Sensor z.B: Blitzdetektor, UV-Index) in der GUI nicht sichtbar zu machen.

Das geht nicht ohne jeweils eigene XML, da lediglich die Kanalzahl dynamisch sein kann, nicht jedoch die Framegrößen

Und dann auch für gleiche Sensoren (Temperatur) jedem Sensor einen eigenen Namen zu geben, das geht ja z.B. beim 8fach Sensor.

Ach so? Wie denn?

harvey637 commented 4 years ago

Hi, reales Beispiel: 8fach Temperatursensor, ungeänderte XML. Es sind 6 Sensoren angeschlossen. Damit ergibt sich unter "Einstellungen-> Geräte der Temperatursensor. Mit einem [+] davor, diese aufklappen. Ursprünglich stand dort "HB-UNI-Sen-TEMP-DS18B20 UNITEMP001:1" .... "HB-UNI-Sen-TEMP-DS18B20 UNITEMP001:8". Dann kann man LINKS auf den Text klicken und bekommt ein "Test" popup. In der ersten Zeile "Name" steht der Text "HB-UNI-Sen-TEMP-DS18B20 UNITEMP001:1" beim ersten Sensor, den kann man ÄNDERN in "Solarspeicher oben". Standardmäßig ist die checkbox "sichtbar" angehakt. Dasselbe mit einem nicht belegtem Sensor (also manuell ein Index anklicken, wo kein Sensor angeschlossen ist), dann das "sichtbar" ABWÄHLEN und auf "ok" klicken.

In der Ansicht "Status und Bedienung -> Geräte" werden dann für DIESEN 8-fach Sensor die Temperaturen entsprechend der Benennung richtig angezeigt, die "sichtbar" abgehakten Sensoren werden garnicht angezeigt.

Auf diese Art und Weise habe ich z.B. meinen Sensoren am Solarspeicher sinnvolle Namen gegeben, auch der Temp-Differenzsensor zeigt mir richtig "Sonnenseite", "Schattenseite", "Erkennung Sonnenschein" für Sensor1, Sensor2, Sensor1 - Sensor2 und eben nicht mehr, weil abgehakt, den 4. Wert (Sensor2 - Sensor1), den will ich garnicht sehen.

Kurz gesagt, wenn in "Einstellungen->Geräte" mehr als ein Channel? aufklapbar ist, dann kann er mit wahlfreiem Namen (inkl spaces) beschrieben (benannt) werden und zusätzlich in der "Status und Bedienung -> Geräte" Ansicht einzeln unsichtbar gemacht werden.

Macht es sehr übersichtlich. Bye the Way, intern läuft alles immer noch über IDs, auch in iobroker. Änderungen werden also sofort sichtbar, auch in Programmen automatisch geändert. Und das hat nichts mit einer Aufteilung in einzelne rf-Telegramme zu tun, da ja z.B. 8fach-Sensor ein oder zwei Telegramme sendet, der Original (und Nachbauten) des Diff-Temperatursensors alles in einem Telegram.

bitte nicht tldr :-))))) cu Harvey

jp112sdl commented 4 years ago

Über Klickibunti war mir schon klar wie das geht. Ich dachte erst du wolltest

Und dann auch für gleiche Sensoren (Temperatur) jedem Sensor einen eigenen Namen zu geben, das geht ja z.B. beim 8fach Sensor.

über die XML realisieren, um irgendwie im Anlernvorgang schon die Sensor-IDs je Kanal mit zu übermitteln (was auch nicht ginge, deshalb war ich so überrascht).

harvey637 commented 4 years ago

Hi, eben nicht über XML, da dieselbe XML ja für mehrere Sensoren (unterschiedliche DEVICE-IDs, aber gleichen DEVICE-MODEL) gilt. Also was z.B. TEMPERATUR in XML ist möchte ich klickbunti gerne mit sinnvollen sprechenden Namen versehen. Was ich (neben ganz vielen anderen Dingen) nicht verstehe ist, warum ein Telegramm (z.B. die ersten vier Werte aus dem 8-fach Sensor) auf getrennten Datenpunkten (ist das der richtige Name?) landen. Die kann ich schön einzeln benennen und unsichtbar machen. Oder aber ein Telegramm (alle Sensoren des TOMschen UNISENSOR oder das Telegramm aus Deinem WEA) "nur" ein Feld in der GUI anlegen, dem ich dann natürlich nur einen Namen vergeben kann und halt "unsichtbar" (damit ja für alle Werte) ziemlicher Blödsinn wäre.

Persönlich fände ich getrennte "Blöcke" oft besser, etwa zusammengehörige Werte (z.B. alles was zum Regensensor gehört) in einem Block, aber "alles was zu Wind gehört" in einen andern Block. Dann kann man etwa ohne Windsensor den Block "Windsensorik" unsichtbar machen. Wenn man wie ich nur Windgeschwindigkeit, aber nicht Windrichtung hat eben Pech. Aber den Blizusensor habe ich nicht .... muss ihn aber trotzdem ansehen, wenn ich nicht in die XML eingreifen will.

Ich versuche für mich mal die XMLs an der Stelle weiter zu analysieren.

Nur als Rückmeldung zu diesem Sensor/Aktor: es geht jetzt über GUI das Auswählen "Relas invertiert" und zusätzlich "Schwellwert" (also über/Unterschreiten von Werten) oder "Bereich" (also Alarmierung innerhalb/ausserhalb eines Bereiches), frei kombiniertbar mit Relais Invertierung. Noch ein bischen Doklu, heute Abend gehts ins Forum. Bei Rumbasteln finde ich das Teil megacool, da es einerseits ein völlig normaler Sensor ist (updInterval), andererseits bei speziellen Werten sofort (Mehrfachmessung innerhalb des updIntervalls) Alarme auslöst. Man muss ja kein Relais/LED dranhaben. Stromverbrauch habe ich noch nicht besonders verfolgt. Aber die Auswertung findet halt sofort im Sensor statt, man braucht (in Programm/Direktverknüpfung) nur auf den VALVESTATE zu reagieren. Alle Parameter sind im GUI konfigurierbar. schon wieder soviel .... grrr :-) cu Harvey

jp112sdl commented 4 years ago

Was ich (neben ganz vielen anderen Dingen) nicht verstehe ist, warum ein Telegramm (z.B. die ersten vier Werte aus dem 8-fach Sensor) auf getrennten Datenpunkten (ist das der richtige Name?) landen. Die kann ich schön einzeln benennen und unsichtbar machen. Oder aber ein Telegramm (alle Sensoren des TOMschen UNISENSOR oder das Telegramm aus Deinem WEA) "nur" ein Feld in der GUI anlegen, dem ich dann natürlich nur einen Namen vergeben kann und halt "unsichtbar" (damit ja für alle Werte) ziemlicher Blödsinn wäre.

Das ist eigentlich ganz einfach. Jeder "Balken" in der WebUI ist ein Kanal.

harvey637 commented 4 years ago

ahhhhhh, VIELEN DANK! Ich glaub, ich bastel man die XML für "meinen" UNISENS-HEIZUNG Variante auf mehrere channel auf. mal schauen! aber dank DEINE HILFE bin ich guten Mutes... cu Harvey

harvey637 commented 4 years ago

PS: bitte nicht hauen :-) diese Unterteilung würde den WEA auch "hübscher" machen ..... und nicht verbaute Sensoren (Blitze, Wind, Regen, ....) auch verstecken.

jp112sdl commented 4 years ago

Ich glaub, ich bastel man die XML für "meinen" UNISENS-HEIZUNG Variante auf mehrere channel auf.

Ist ne Menge Aufwand, weil du ja dann für jeden Datentyp nun einen eigenen Kanal in der XML anlegen musst - inkl seiner MASTER-, VALUE- und LINK - Paramsets.

Aber man lernt bei der Bastelei ne Menge über die WebUI und wie man von einem Stolperstein zum nächsten fällt. 🤓

diese Unterteilung würde den WEA auch "hübscher" machen .....

Da geh ich keinesfalls ran, weil halt zu jedem Datenpunkt noch das Channel-Field kommt. Overhead ohne Ende bei der Menge an Datenpunkten.

Du kannst ja gern was bauen und es als Alternative anbieten.

TomMajor commented 4 years ago

jetzt haben sich hier in der Issue doch einige interessante Informationen zu AddOns, Channels und xml angesammelt, cool :sunglasses: (falls es dem geneigten Leser nicht tldr ist :crying_cat_face: )

Werfe noch einen link zum Thema in den Ring, den ich neulich zufällig entdeckt hatte, leider unvollständig: https://github.com/homematic-community/ccu-addon-howto

harvey637 commented 4 years ago

Hi, ja eine lockere Runde :-) Erste Versuche schonmal gut:

    <channel index="1" type="WEATHER" autoregister="true">
      <link_roles>
        <source name="WEATHER_TH" />
      </link_roles>
      <paramset type="MASTER" id="HB-UNI-Sensor1_master" />
      <paramset type="VALUES" id="HB-UNI-Sensor1_values">
        <parameter id="TEMPERATURE" operations="read,event">
          <logical type="float" min="-99.9" max="120.0" unit="▒C">
            <special_value id="NO_SENSOR" value="-99.9" />
          </logical>
          <physical type="integer" interface="command" value_id="TEMPERATURE">
            <event frame="WEATHER_EVENT" />
          </physical>
          <conversion type="float_integer_scale" factor="10.0" />
          <description>
            <field id="AutoconfRoles" value="WEATHER" />
          </description>
        </parameter>
      </paramset>
    </channel>
    <channel index="2" type="WEATHER" autoregister="true">
      <link_roles>
        <source name="WEATHER_TH" />
      </link_roles>
      <paramset type="MASTER" id="HB-UNI-Sensor1_master" />
      <paramset type="VALUES" id="HB-UNI-Sensor1_values">
        <parameter id="AIR_PRESSURE" operations="read,event">
          <logical type="float" min="500.0" max="1200.0" unit="hPa">
            <special_value id="NO_SENSOR" value="0.0" />
          </logical>
          <physical type="integer" interface="command" value_id="AIR_PRESSURE">
            <event frame="WEATHER_EVENT" />
          </physical>
          <conversion type="float_integer_scale" factor="10.0" />
          <description>
            <field id="AutoconfRoles" value="WEATHER" />
          </description>
        </parameter>

führt dazu, dass den TEMPERATURE einen eigenen "channel" == Block in der GUI bekommt, mit allen Möglichkeiten, den channel/Block zu benennen (z.B. "Wintergarten Temperatur am Fenster") oder halt auch auszublenden. Die Aufteilung der anderen Werte (humidity, airpressure, valvestate,customdata) ist wohl nur Tipparbeit.

Dabei ist es wohl egal, wie die Werte ankommen (in einem Telegramm) , sie müssen nur benannt und dem channel zugeordnet werden:

  <frames>
    <frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="1" type="0x70">
      <parameter type="integer" signed="true"  index="9"  size="1.7" param="TEMPERATURE" />
    </frame>
    <frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="2" type="0x70">
      <parameter type="integer" index="11" size="2.0" param="AIR_PRESSURE" />
      <parameter type="integer" index="13" size="1.0" param="HUMIDITY" />
      <parameter type="integer" index="14" size="4.0" param="LUX" />
      <parameter type="integer" index="18" size="1.0" param="VALVE_STATE" />
      <parameter type="integer" index="19" size="2.0" param="OPERATING_VOLTAGE" />
      <parameter type="integer" index="22" size="0.4" param="UVINDEX" />
    </frame>
  </frames>

Gerade für einen universellen Sensor, wo oft nur bestimmte Sensoren verwenden werden finde ich das GUT.

Und so sieht dann die Checkbox aus (ohne language Anpassung):

    <parameter id="INVERT_RELAY">
      <logical type="boolean" default="false"/>
      <physical type="integer" interface="config" list="0" index="41.0" size="0.1" />
    </parameter>
    <parameter id="LEVEL_THRESHOLD">
      <logical type="boolean" default="false"/>
      <physical type="integer" interface="config" list="0" index="41.1" size="0.1" />
    </parameter>

der dazu gehörende Code:

    bool     measureFreq(uint8_t value) const { return this->writeRegister(0x28, value & 0xff); }
    uint8_t  measureFreq() const { return ( this->readRegister(0x28, 0) <= 2 ? 2 :  this->readRegister(0x28, 0) ); }

    bool     invertRelay(uint8_t value) const { return this->writeRegister(0x29, value & 0x01); }
    bool     invertRelay() const { return (this->readRegister(0x29, 0) & 0x01); }

    bool     levelThreshold(uint8_t value) const { return this->writeRegister(0x29, value & 0x02); }
    bool     levelThreshold() const { return (this->readRegister(0x29, 0) & 0x02); }

der auch noch die "measureFreq" auf minimal 2 prüft.

Bin ganz zufrieden! Daher ganz besonderen Dank an Jerome, der mich "angefüttert" und hungrig gemacht hat! cu Harvey

jp112sdl commented 4 years ago

Dabei ist es wohl egal, wie die Werte ankommen (in einem Telegramm) , sie müssen nur benannt und dem channel zugeordnet werden: Die Aufteilung der anderen Werte (humidity, airpressure, valvestate,customdata) ist wohl nur Tipparbeit.

<frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="1" type="0x70">
....
<frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="2" type="0x70">

Brauchst halt n Telegramme. Wenn man das noch weiter aufdröselt, werden es immer mehr. Ich persönlich halte nicht viel davon, das auf einzelne fixed_channel aufzuteilen. Jedes einzelne Telegramm ist ja so schon mind. 10 Byte (Counter,From,To,Flags,Kanal,...) lang. Und daran hängen dann je Kanal vielleicht noch 1...4 Byte als Wert. Dazu muss man zwischen den Aussendungen noch ein paar Millisekunden warten, damit die Zentrale es verarbeiten kann. Bei der CCU2 sind das rund 400ms. Ich weiß es nicht, ob es das "sieht hübsch aus" aufwiegt. Mein Motto ist eher immer "function first" ;)

Es wäre auch Payload-Verschwendung, im Channel 2 erst ab Index 11 weiterzumachen. Das Telegramm wird unnötig mit 2 Bytes aufgefüllt.

Bin ganz zufrieden!

Optisch mag es vielleicht deinen Vorstellungen entsprechen, aber es ist entfernt vom Homematic-Konzept anderer (originaler Geräte) wo es zB jeden Frame(typ) in einem Gerät nur 1x gibt.

harvey637 commented 4 years ago

Hi @ Jerome, Also es sieht so aus, als würde EIN Telegramm (in diesem Fall) ausreichen. es geht über die Leitung:

DS18x20 Temperature     : 210
DS18x20 Temperature     : 205
Alarm < lower, Relay: 1
<- 17 03 84 70 A5A525 00FFFF 00 CD 00 00 00 00 00 00 00 01 04 DA 00 00  - 13127
DS18x20 Temperature     : 201
DS18x20 Temperature     : 198

Die Temperaturen sind sind "nur" die Messungen, die NICHT zum Senden geführt haben, dann kommt die Messung mit 20.5°, die ist lower threshold_lower=210, also wird gesendet. Die Sendung ist ein einziges Telegramm, 00 CD = 205(dez) ist die Temperatur, dann 00 00 airpressure, 00 Humidity, 00 00 00 00 brightness, 01 digInputState (ja, das Relais ist angezogen) , 04 DA = 1.24 V Batterie, 00 00 customData.

Es wird also mit "minimalem" Funkaufwand = ein Telegramm ALLE Daten transportiert!

Das Ergebnis landet tatsächlich in getrennten Kanälen, wobei ich zum Test nur channel1, channel5, channel6 verwende.

harvey637 commented 4 years ago

grafik

grafik

harvey637 commented 4 years ago

Man sieht schön, dass die Batteriemessung 12:01 war (reset device), die Ventilposition/Relais änderten sich um 12:45 wegen Unterschreitung Schwellwert (20.5 < 21.0) und 10 Minuten (=updInterval) weitere Temperaturmessung

Der Sketch ist komplett unverändert, es wurde nur das XML geändert, Sensor ab/angelernt und die Aufteilung in Kanäle ging!

jp112sdl commented 4 years ago

Die Sendung ist ein einziges Telegramm,

Ja, mit haufenweisen unnützen 0-Bytes ;)

ein Telegramm ALLE Daten transportiert!

Wenn es für dich funktioniert - ok. Das kann aber nur eine "Krücke" bzw. Zufall (oder ein Bug?) sein, dass es geht. Du definierst fixe Kanäle im Frame. Und ein Telegramm kann zu einer Zeit nur eine Kanalinformation enthalten.

harvey637 commented 4 years ago

Ja, die vielen 00 Byte sind dem Universalsensor geschuldet, ist leider so. Er KÖNNTE ja auch mehrere Sensoren (bmp280, max44009, ....) angeschlossen haben und trotzdem mit einem Sketch/XML die Werte transportieren. By the way, der 8-fach Temperatursensor sendet doch auch die ersten 4 Temperaturen im ersten Telegramm, falls notwendig die zweiten 4 Temperaturen im zweiten Telegramm. Trotzdem sind IMMER jede Temperatur für sich ein channel. Also das scheint mir schon so gewollt zu sein. Das "alte" XML hatte immer alle 8 möglichen Temperaturen, das wurde ja irgendwann mal auf dynamisch per "found xx ds18b20" umgestellt. Aber immer waren im einem (ersten oder zweitem) Telegramm vier Temperaturen enthalten.

harvey637 commented 4 years ago

PS: ebenso beim Temperatur-differenz Sensor: beide Temperaturen und beide Differenzen in einem Telegramm, Ergebnis in vier Kanälen.

jp112sdl commented 4 years ago

By the way, der 8-fach Temperatursensor sendet doch auch die ersten 4 Temperaturen im ersten Telegramm, falls notwendig die zweiten 4 Temperaturen im zweiten Telegramm. Trotzdem sind IMMER jede Temperatur für sich ein channel.

Der 8fach Temp sendet alle Werte auf einem Kanal. Vor jedem Temp-Wert steht ein channel_field Parameter, worüber die CCU dann die Temperatur dem Kanal zuordnet.

Und ja - es sind 2 Telegramme, weil mit 4 Sensoren die maximal mögliche Telegrammlänge erreicht ist. Das ist halt die Krücke mit dem delay zwischen den 2 Aussendungen. Ohne dem klappts bei der CCU2 nicht.

Also das scheint mir schon so gewollt zu sein Wenn das alles so egal ist, wie du dir das jetzt umgestrickt hast, dann wäre ja die Entwicklung/Erfindung der channel_field Parameter vom Hersteller völlig unnütz gewesen. ;)

Ich zumindest werde weiterhin dabei bleiben - werden mehrere Werte übertragen, die auf unterschiedlichen Kanälen dargestellt werden sollen, wird ihnen ein channel_field vorangestellt.

harvey637 commented 4 years ago

Vielen Dank für Deine Geduld! (no joke). Es geht mir ja auch nicht darum, meine XML als super darzustellen, und es fehlt mir Erkenntnis zum Unterschied "fixed_channel" und "channel_field". Empirisch (also durch runfummeln) habe ich gesehen, dass ein Telegramm (mit mehreren Werten an festen Positionen) die Werte in getrennten <channel index="(1-x) type...." darstellen kann.

Dazu habe ich z.B. wds30ot2 angesehen: da gibt es generierte channel (index=1 ... count=4) also channel1 channel2 channel3 channel4. Dann kommt channel index=5. in den Frames sehe ich eine Zuordnung zu channel5:

                <frame id="WEATHER_EVENT" direction="from_device" event="true" fixed_channel="5" type="0x70">
                        <parameter type="integer" signed="true" index="9.0" size="1.7" param="TEMPERATURE"/>
                </frame>

und die Zuordnung zu den channel1 ... channel4 über channel_field=...

 <frame id="MEASURE_EVENT" direction="from_device" event="true" type="0x53" channel_field="10.0:0.6">
                        <parameter type="integer" signed="true" index="11.0" size="2.0" param="TEMPERATURE"/>
                </frame>

Dein Einwand öffnet mir so langsam die Augen - ehrlich vielen Dank!

Ich habe volles Verständnis, dass Du nicht aus meinem Schönheitsgedanken heraus umfangreich ändern willst (WEA), aber ich spiele das Experiment mal auf den UNI-SENSOR (was ja nicht deine Baustelle ist, aber ich lerne ja, und vielleicht interessiert das Tom):

In das (eine einzige, bleibt kurz genug) Telegramm werden vor die Messwerte "uniqe numbers" geschrieben, etwa "0x42" für Temperatur, "0x43" für airPressure, "0x44" für brightness und und und. Dann wird aus diesen uint8_t Feldern Bits maskiert entsprechend Anzahl der channels und als channel_field verwendet (aahhhh! : fixed_channel=feste Ziffer .... channel_field= dynamisch aus Telegramm). Der channel (channel index=...) muss natürlich definiert sein, dynamisch mit count=xxx oder fest durch eintippen. Das klappt gut leider nur für "viele" gleich große (Anzahl Byte) Werte, also etwa viele Temperaturen. Und für mehrere Telegramme, die dann auch gleichen Aufbau haben müssen, also an festen Positionen sich die Nummer des channels befindet und die Messwerte. Also Mist, der UNI-SENSOR passt nicht zu dynamischen channels aus channel_field=..., aber zu fixed_channel=xxx. Vielleicht ist es doch nicht sooooo viel Aufwand, mit den fixed channels den WEA in "Regen" - "Wind" - "Blitz" - "Temp/Druck/Feuchtigkeit" aufzuteilen :-))))) Bye the way: BAT_LOW hat fixed_channel="*", also in jedem channel vorhanden.

Also vielen Dank, ich verneige mein Haupt und versuche mal selbst XML zu bauen und weniger zu schwafeln. Aber ich möchte im Forum nicht allzu falsche Dinge präsentieren, da dort manchmal Freunde mit geringem technischen Hintergrund alles für bare Münze nehmen. cu Harvey Hat mir SEHR geholfen!

harvey637 commented 4 years ago

Hi @ Jerome, völlig OFFTOPIC, aber ich las zufällig in Elektor 2004-05 von einem Windsensor, der die Windrichtung ganz ohne weitere Sensoren erkennt: eine Halbkugel hat ein "Fähnchen", und gemessen wird die Geschwindigkeitsänderung in der Umdrehung, wobei die Windrichtung in der Mitte der Beschleunigung und Abbremsung liegt. Und Elektor 1979-07_08 Schaltung 46 für eine Richtungserkennung mit BCD-Code (und Verbesserung auf GRAY-Code) .... Also ein 40 Jahre altes Thema :-))))) cu Harvey

jp112sdl commented 4 years ago

Dazu habe ich z.B. wds30ot2 angesehen: da gibt es generierte channel (index=1 ... count=4) also channel1 channel2 channel3 channel4. Dann kommt channel index=5.

Kanal 1-4 sind hier vom Typ 0x53 (Mess-/Sensordaten).

Kanal 5 ist der fixe Kanal, der für Direktverknüpfungen verwendet werden kann. Er ist vom Typ 0x70 - Wetterdaten. Auf ihm wird ein aus Kanal 1...4 (in der WebUI konfigurierbarer) Wert übermittelt. Gerade bei Direktverknüpfungen (mit Originalgeräten) ist es extrem wichtig, sich an die vorgegebenen Typen, Kanäle, Indizes zu halten. Denn der Empfänger erwartet ein konkretes Telegramm. Die Temperatur steht bei Homematic z.B. immer an Index 9

TomMajor commented 4 years ago

Link zu Harvey Arbeit: https://homematic-forum.de/forum/viewtopic.php?f=76&t=54495#p545308