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: 2719
Registriert: 20.11.2016, 20:01
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: 528
Registriert: 13.12.2016, 21:14
Wohnort: Altmühltal
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: 2719
Registriert: 20.11.2016, 20:01
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: 528
Registriert: 13.12.2016, 21:14
Wohnort: Altmühltal
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: 295
Registriert: 22.05.2018, 10:23

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: 121
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: 121
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: 295
Registriert: 30.08.2017, 23:25
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

Antworten

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