Füllstandsensor mit Druck- statt US-Sensor

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

Moderator: Co-Administratoren

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

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

Beitrag von papa » 10.03.2019, 18:59

Arg - Jerome - warum ist das SendeInterval beim Sen-LEV_US in Regsiter 32 und beim Sen-PRESS in 33 ? Muss ich doch glatt noch eine extra Registerdefinition anlegen.
Anfragen zur AskSin++ werden nur im Forum beantwortet

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

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

Beitrag von jp112sdl » 10.03.2019, 19:32

Hmm... gute Frage. Hab mir damals noch keine Gedanken darüber gemacht :roll: und der CCU isses egal.

VG,
Jérôme ☕️

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

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

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

Beitrag von papa » 10.03.2019, 20:59

Der HB-UNI-Sen-PRESS sollte jetzt mit FHEM gehen - bitte mal testen.
Anfragen zur AskSin++ werden nur im Forum beantwortet

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

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

Beitrag von DocMarten » 10.03.2019, 21:27

Vieln Dank Papa - von https://github.com/pa-pa/AskSinPP/blob/ ... PCustom.pm holen?
Grüße
Martin
Standort 1: FS20 + Homematic mit CUL und FHEM (immer aktuelle Ver.) auf Raspberry Pi
Standort 2: Homematic (Wired + einige Funkmodule) über CCU2 und PocketHome HD, VCCU auf Raspberry
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods)

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

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

Beitrag von papa » 10.03.2019, 21:29

ja
Anfragen zur AskSin++ werden nur im Forum beantwortet

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

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

Beitrag von DocMarten » 10.03.2019, 22:28

Klappt prinzipiell auf Anhieb, vielen Dank Papa. Ich muss jetzt nur noch etwas im Sketch herumdilettantieren, damit das (einzige) Reading "pressure" das berechnete Ergebnis in Litern reflektiert (oder ich mache das in fhem). Derzeit zeigt es noch (durchaus mit der Eintauchtiefe korrespondierende) Werte zwischen 0 und 0,6 (bei ca. 30 cm Eintauchtiefe).
Die Behältermaße für die Berechnung Druck <-> Inhalt würde ich, ebenso wie die Messlänge des Sensors (5 oder 10 oder ? Meter) im Sketch definieren, nicht nur, weil deren Einbindung als Registerwerte (?) meine Fähigkeiten übersteigen würde, sondern auch, weil ich meine, dass a) sich die Maße eines Beckens eher selten ändern, und b) Benutzer dieser Homebrews ohnehin selbst flashen müssen. Da finde ich es - zumindest für mich - einfacher, die individuellen Parameter gleich in der ino-Datei einzutragen, als später im WebUI einzeln zu konfigurieren.
Grüße
Martin
Standort 1: FS20 + Homematic mit CUL und FHEM (immer aktuelle Ver.) auf Raspberry Pi
Standort 2: Homematic (Wired + einige Funkmodule) über CCU2 und PocketHome HD, VCCU auf Raspberry
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods)

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

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

Beitrag von DocMarten » 13.03.2019, 11:33

DocMarten hat geschrieben:
10.03.2019, 22:28
Ich muss jetzt nur noch etwas im Sketch herumdilettantieren, damit das (einzige) Reading "pressure" das berechnete Ergebnis in Litern reflektiert (oder ich mache das in fhem). Derzeit zeigt es noch (durchaus mit der Eintauchtiefe korrespondierende) Werte zwischen 0 und 0,6 (bei ca. 30 cm Eintauchtiefe).
"Etwas" ist gut... ich bin seit Tagen in der C-Arithmetik-Hölle gefangen und finde keinen Ausgang. Könnt Ihr mir einen Tipp geben?
Konkret bei der Be- bzw. Umrechnung der Werte. Ich glaube, ich habe jetzt alles durchprobiert, was ich so in Tutorials finden konnte: uint32_t statt uint16_t, long (mit L auf der anderen Seite), Angabe der Daten in cm oder m u.v.m. Auf dem seriellen Monitor ist alles gut. Aber ich bekomme es einfach nicht hin, dass auch der gefunkte Wert die richtige Anzahl von Stellen hat. Ich könnte das zwar in fhem oder in der CCU berechnen lassen, fände es aber eleganter, wenn das Teil gleich die richtigen Werte liefern würde.
pressure
allein ist z.B. 19,6 wenn ContentLiters 1960 ist.
setze ich
pressure = ContentLiters * 10
so wird 196 gefunkt.
Setze ich aber
pressure = ContentLiters * 100
so wird nicht 1960 übermittelt, sondern z.B. 645

Mir ist klar, dass das wohl irgendwas mit der bitweisen Verschiebung und dem "Overflow" zu tun hat in

Code: Alles auswählen

class WeatherEventMsg : public Message {
  public:
    void init(uint8_t msgcnt, uint8_t channel, uint16_t pressure) {

      Message::init(0x0e, msgcnt, 0x53, BCAST , 0x00, 0xc1);
      pload[0] = channel  & 0xff;
      pload[1] = (pressure >> 8) & 0xff;
      pload[2] = pressure & 0xff;
    }
};
Daszu habe ich aber nichts in der Asksin-Doku gefunden - warum muss hier bitweise verschobene werden? Gibt es eine Begrenzug des Wertebereichs und wenn ja, wie kann man diese aufheben?

Sketch anbei, hier die entsprechenden Auszüge:


So habe ich die Parameter definiert:

Code: Alles auswählen

  #define SensorLength        500
  #define FillHeight          1.30
  #define CaseWidth           1.57
  #define CaseLength          4.12
  #define ANALOG_SOCKET_VALUE 201
Und so mache ich die Berechnung und zeige sie im seriellen Monitor an:

Code: Alles auswählen

      float _p = ((sens_val-ANALOG_SOCKET_VALUE)*100.0)/(1024.0-ANALOG_SOCKET_VALUE);  
      #define ContentTotal  CaseWidth * CaseLength * FillHeight
      #define ContentPercent  _p * SensorLength / FillHeight / 100
      #define ContentLiters ContentTotal / 100 * ContentPercent * 1000

//    pressure = _p > 0 ? _p : 0;
      pressure = ContentLiters * 10;
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(") Analogwert: ")); DDECLN(sens_val);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       Fuellstand in Prozent: ")); DDECLN(ContentPercent);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       Fuellstand in Litern: ")); DDECLN(ContentLiters);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       Messung: ")); DDECLN(_p);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       sens_val: ")); DDECLN(sens_val);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       ContentTotal: ")); DDECLN(ContentTotal);
      DPRINT(F("+Pressure  (#")); DDEC(number()); DPRINT(F(")       Pressure: ")); DDECLN(pressure);
        }
Danke für Eure Hilfe &
Viele Grüße
Martin
Dateianhänge
füllstandsensor_DEV_last.txt
(8.51 KiB) 72-mal heruntergeladen
Standort 1: FS20 + Homematic mit CUL und FHEM (immer aktuelle Ver.) auf Raspberry Pi
Standort 2: Homematic (Wired + einige Funkmodule) über CCU2 und PocketHome HD, VCCU auf Raspberry
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods)

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

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

Beitrag von jp112sdl » 13.03.2019, 11:42

DocMarten hat geschrieben:
13.03.2019, 11:33
Mir ist klar, dass das wohl irgendwas mit der bitweisen Verschiebung und dem "Overflow" zu tun hat in
Das heißt, wenn du dir noch direkt in der Message den pressure-Wert ausgeben lässt

Code: Alles auswählen

class WeatherEventMsg : public Message {
  public:
    void init(uint8_t msgcnt, uint8_t channel, uint16_t pressure) {
      DPRINT("XXX ");DDECLN(pressure); 
      Message::init(0x0e, msgcnt, 0x53, BCAST , 0x00, 0xc1);
      pload[0] = channel  & 0xff;
      pload[1] = (pressure >> 8) & 0xff;
      pload[2] = pressure & 0xff;
    }
};
kommt noch XXX 1960 ?

VG,
Jérôme ☕️

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

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

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

Beitrag von DocMarten » 13.03.2019, 11:50

Werde ich heute Abend umgehend ausprobieren. Das ist auch so ein bisschen mein Problem - dass ich zu vielen Sachen keine Infos im Netz finde und so nicht verstehe, was genau sie tun und wo/wie man sie einsetzen kann, z.B. DDECLN
Standort 1: FS20 + Homematic mit CUL und FHEM (immer aktuelle Ver.) auf Raspberry Pi
Standort 2: Homematic (Wired + einige Funkmodule) über CCU2 und PocketHome HD, VCCU auf Raspberry
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods)

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

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

Beitrag von jp112sdl » 13.03.2019, 11:52

Es gibt keine Docu... muss man sich ein wenig durch die .h Files hangeln...
Debug.h

D = Debugausgabe
DEC = Decimal, HEX = Hexadezimal, PRINT = Text
LN = mit Linefeed (Zeilenumbruch)

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“