Füllstandsensor mit Druck- statt US-Sensor

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

Moderator: Co-Administratoren

jp112sdl
Beiträge: 3024
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 7 Mal
Danksagung erhalten: 31 Mal
Kontaktdaten:

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von jp112sdl » 14.03.2019, 19:16

DocMarten hat geschrieben:
14.03.2019, 17:31
Was bringt mir das?
Dir nichts. :mrgreen:
Wie gesagt - 1 Byte kann nur die Information 0 - 255 tragen.
1234 wird also in 2 Bytes (00000100 11010010)zerlegt und übertragen
Byte 1: 00000100
Byte 2: 11010010

Auf der Gegenseite zusammengesetzt ergibt das wieder... *Trommelwirbel*... 00000100 11010010 :arrow: 1234 :wink:

VG,
Jérôme

stan23
Beiträge: 587
Registriert: 13.12.2016, 21:14
Wohnort: Altmühltal
Hat sich bedankt: 13 Mal
Danksagung erhalten: 13 Mal
Kontaktdaten:

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von stan23 » 14.03.2019, 20:27

jp112sdl hat geschrieben:
14.03.2019, 17:06
Das & 0xff liefert von einem Wert der größer als 8 Bit (1 Byte) ist, die 8 Bits ganz rechts.
Wobei der Compiler das implizit eh schon macht, weil pload ein uint8_t ist.
Viele Grüße
Marco

RaspberryMatic
~60 Geräte (HM, HmIP, HMW, HBW, AskSin)

jp112sdl
Beiträge: 3024
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 7 Mal
Danksagung erhalten: 31 Mal
Kontaktdaten:

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von jp112sdl » 14.03.2019, 20:44

stan23 hat geschrieben:
14.03.2019, 20:27
jp112sdl hat geschrieben:
14.03.2019, 17:06
Das & 0xff liefert von einem Wert der größer als 8 Bit (1 Byte) ist, die 8 Bits ganz rechts.
Wobei der Compiler das implizit eh schon macht, weil pload ein uint8_t ist.
Aber so ist es fix... auch wenn man für einen anderen Prozessor (STM32 statt 328P) kompiliert (little/big endian) !?

VG,
Jérôme

stan23
Beiträge: 587
Registriert: 13.12.2016, 21:14
Wohnort: Altmühltal
Hat sich bedankt: 13 Mal
Danksagung erhalten: 13 Mal
Kontaktdaten:

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von stan23 » 14.03.2019, 20:50

Aus dem Bauch würde ich sagen dass ein uint8_t immer die untersten 8 Bit bekommt, unabhängig von Endianess und CPU-Architektur.

Aber du hast schon recht, besser man spezifiziert es übergenau, als dass ichgendein Compiler das falsch macht.
Viele Grüße
Marco

RaspberryMatic
~60 Geräte (HM, HmIP, HMW, HBW, AskSin)

papa
Beiträge: 325
Registriert: 22.05.2018, 10:23
Danksagung erhalten: 4 Mal

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von papa » 14.03.2019, 21:04

jp112sdl hat geschrieben:
14.03.2019, 20:44
Aber so ist es fix... auch wenn man für einen anderen Prozessor (STM32 statt 328P) kompiliert (little/big endian) !?
Genau - das ganze rumgeschifte ist nur dafür da, das in der Nachricht die Reihenfolge der Byte immer gleich ist - unabhängig von der Architektur der CPU (big/little endian).
Anfragen zur AskSin++ werden nur im Forum beantwortet

DocMarten
Beiträge: 122
Registriert: 12.11.2006, 23:33

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von DocMarten » 08.04.2019, 13:19

Nur damit Ihr nicht denkt, dass ich vor lauter Bit-Shiften in die Zisterne gefallen bin: Ich habe aus meinem Drucksensor ein Geburtstagsgeschenk gemacht und warte nun auf die Neubestellung. Dann geht's weiter.
Grüße
Martin

DocMarten
Beiträge: 122
Registriert: 12.11.2006, 23:33

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von DocMarten » 25.06.2019, 11:01

Hallo zusammen,
... und weiter geht's. Der neue Drucksensor ist endlich da, und ich bin vor Ort an den Zisternen.
Kleine Planänderung: da der US-Sensor in der Regenwasserzisterne doch ganz brauchbar funktioniert, möchte ich den Drucksensor für die Trinkwasserzisterne einsetzen, und zwar mit der CCU2 (und nur sekundär via VCCU mit fhem). Da habe ich auch Strom für ein Netzteil.

Wert wird auch angezeigt, allerdings geteilt durch den Faktor 100 (also z.B. 768.56 statt 76856 Liter). Und die Beschriftung stimt natürlich auch nicht (Druck bzw. bar).

Nun bin ich auf dem Weg, das Modul zu modifizieren, um im zweiten Schritt ein Neues daraus zu erstellen.

In der entpackten (alten) JP-HB-Devices-addon bin ich in zwei Dateien fündig geworden:
in \addon\firmware\rftypes\hb-uni-sen-press.xml ist als Einheit "bar" definiert und als float_integer_scale factor 100. Ich habe das mal in Liter und 10 abgeändert:

Code: Alles auswählen

       <paramset type="VALUES" id="hb_press_values">
          <parameter id="UNI_PRESSURE" operations="read,event">
             <logical type="float" min="0.0" max="100000.0" unit="Liter" />
             <physical type="integer" interface="command" value_id="UNI_PRESSURE">
             <event frame="PRESSURE_EVENT"/>
             </physical>
             <conversion type="float_integer_scale" factor="10"/>
          </parameter>
       </paramset>
Und in \addon\install_hb-uni-sen-press "Druck" zu "Inhalt"

Code: Alles auswählen

<logical type="float" min="0.0" max="100000.0" unit="Liter" />
Dann dachte ich mir: Tar-Archiv erstellen, dieses dann nochmals gzippen und - nach dem Löschen der vorherigen Version - auf die Zentrale hochladen. Schlägt aber fehl ohne Fehlermeldung. Daher meine Fragen:

1. Gibt es da noch irgendwelche Checksum-Tests, die das Installieren nach Modifikationen verhindern?
2. Ist es evtl. sinnvoller, die Dateien per SSH auf der Zentrale zu editieren?
3. Gibt es irgendwo eine Basis-Doku, welche Dateien für ein neues Modul im Addon angelegt bzw. kopiert und umbenannt werden müssen? Wie findet die Zuordnung statt - alles über den Modulnamen?
Danke für Eure Hilfe & viele Grüße
Martin

TomMajor
Beiträge: 379
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 5 Mal
Danksagung erhalten: 15 Mal
Kontaktdaten:

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von TomMajor » 25.06.2019, 11:41

Habe mir das xml nicht angeschaut um das es geht, nur allgemein meine Erfahrungen:
- chksum Tests gibt es nicht fürs AddOn
- wenn du AddOn modifizierst und neu installierst solltest du danach den Sensor aus der Zentrale löschen und neu anlernen
- wenn du Faktor 100 im xml änderst muss der gesendete Wert im sketch auch dafür angepasst werden
- am saubersten ist es build.sh für das Neuerstellen des AddOn zu verwenden
- Für Tests kannst du immer direkt über SSH editieren, danach aber S70ReGaHss und S61rfd neustarten damit die Änderungen wirksam werden
Viele Grüße,
Tom

DocMarten
Beiträge: 122
Registriert: 12.11.2006, 23:33

Re: Füllstandsensor mit Druck- statt US-Sensor

Beitrag von DocMarten » 04.07.2019, 10:04

Hallo,
vielen Dank für die Hinweise, die ich zu einem späteren Zeitpunkt gut werde gebrauchen können.
Mir ist allerdings mittlerweile eine "Erleuchtung" gekommen, die die Umsetzung der Füllstandmessung meiner beiden Zisternen radikal verändert hat und außer dem Sensor und dem Powerbooster keine weitere Hard- und Software braucht. Ich nutze hier seit Jahrenden genialen PoolController fürs Schwimmbecken (Steuerung der Salzelektrolyse, Pumpe,ph uvm., hat sich vom Fanprojekt mittlerweile zu einem richtigen Produkt entwickelt: http://www.poolsteuerung.de). Und irgendwann fiel mir ein, dass dieser u.a. auch (von mir bislang ungenutzte) Analogeingänge bietet, z.B. für Drucksensoren am Sandfilter. Dann habe ich doch tatsächlich ins Handbuch geschaut, und zwei der Analogeingänge sind bereits ganz explizit auf 4-20mA Drucksensoren ausgelegt, inkl. internem 150 Ohm-Widerstand.
Der Poolcontroller wird über 5V versorgt, also den Booster angeklemmt und auf 24 V eingeregelt, Kabel verlegt, mit dem internen Calculator Offset und Gain berechnet, und schon wird mir der Füllstand in Litern im Web-UI des Poolcontrollers angezeigt!
Da ich vor einiger Zeit schon mal an einem fhem-Modul herumgeschraubt hatte, um die Daten des Controllers auch in fhem zu holen, war hier schon alles vorbereitet. Nur noch eine Systemvariable in der CCU2 angelegt, die fhem über vccu mit dem aktuellen Wert aus dem Poolcontroller füllt, und schon ist der Wert auch im Homematic-Universum nutzbar (etwa in der PocketHome-Visualisierung).
Hier noch einmal vielen Dank für Eure Unterstützung und
Viele Grüße
Martin
Dateianhänge
poolcontroller.jpg

Antworten

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