Generierte Readings bei Autocreate

Begonnen von Markus., 16 März 2019, 13:13:02

Vorheriges Thema - Nächstes Thema

Markus.

Hallo Zusammen,

Wovon hängen eigentlich die generierten Readings und/oder reading mappings ab bei einem Mysensors device das mit autocreate angelegt wird? Von den Presentstions im Sketch oder werden per default einige angelegt umd das Nodetyp unabhängig?
Es geht hier um folgenden Sketch zur Messung der Bodenfeuchtigkeit:

#define MY_DEBUG
#define MY_SPECIAL_DEBUG
#define MY_SIGNAL_REPORT_ENABLED

// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_RFM69
//#define MY_RS485
#define MY_RFM69_FREQUENCY RFM69_868MHZ

#define MY_BAUD_RATE 38400

#include <MySensors.h>
#include <SPI.h>
#include <Vcc.h>
#include <Streaming.h>
#include <math.h>

//#define SLEEP_TIME_15min  900000    // 15min x 60s = 900000 ms -13% = 783000                (my arduinos show a delay of 8s/min = 13%)
#define SLEEP_TIME_15min  300000
#define SLEEP_TIME_1h     3600000   // 1 h = 1*60*60000 = 3600000 ms -13% = 3132000 ms
#define SLEEP_TIME_2h     7200000   // 2 h = 2*60*60000 = 7200000 ms -13% = 6264000 ms
#define SLEEP_TIME_3h     10800000  // 3 h = 3*60*60000 = 10800000 ms -13% = 9396000 ms

#define VERSION "3.0"
#define PIN_ALIM1 2                                   // Connect to input of resistor
#define PIN_ALIM2 6                                   // Connect to input of measuring probe
#define PIN_LECTURA A1

//#define AGUA_DIR            800.0
//#define AGUA_INV            160.0
//#define AIRE_DIR            0.0
//#define AIRE_INV            1023.0
#define AGUA_DIR            300.0
#define AGUA_INV            356.0
#define AIRE_DIR            0.0
#define AIRE_INV            1023.0
#define TIEMPO_LECTURA      10
#define MAX_REP_LECTURA     20
#define MAX_REPORTING_LOOPS 4

// Battery calibration (Li-ion)
const float VccMin   = 3.0;                         // Minimum expected Vcc level, in Volts.
const float VccMax   = 4.2;                         // Maximum expected Vcc level, in Volts.
const float VccCorrection = 3.82/3.74;              // Measured Vcc by multimeter divided by reported Vcc

#define CHILD_MOIST_ID 1
MyMessage msgmoist(CHILD_MOIST_ID, V_LEVEL);
Vcc vcc(VccCorrection);

int count=0;
signed int oldv1=0, oldv2=0;
float oldresultcb=0;

void setup() {
#ifdef MY_DEBUG
  Serial.begin(38400);
#endif
  analogReference(DEFAULT);
  pinMode(PIN_LECTURA, INPUT);
  pinMode(PIN_ALIM1, OUTPUT);
  pinMode(PIN_ALIM2, OUTPUT);
}

void presentation(){
    sendSketchInfo("Sensor de humedad", VERSION);
    present(CHILD_MOIST_ID, S_MOISTURE, "Humedad suelo");
}

void loop()
{
  {
   signed int value1=0, value2=0, i=0;
    float result1, result2, resultp, resultcb;

    //Loop until readings are stable or max number of readings is reached
    do {
      oldv1=value1; oldv2=value2;
      wait(TIEMPO_LECTURA);
      digitalWrite(PIN_ALIM1, HIGH);
      digitalWrite(PIN_ALIM2, LOW);
      wait(TIEMPO_LECTURA);
      value1 = analogRead(PIN_LECTURA);

      digitalWrite(PIN_ALIM1, LOW);
      digitalWrite(PIN_ALIM2, HIGH);
      wait(TIEMPO_LECTURA);
      value2 = analogRead(PIN_LECTURA);;
      digitalWrite(PIN_ALIM1, LOW);
      digitalWrite(PIN_ALIM2, LOW);
    } while (((oldv1 != value1) && (oldv2 != value2)) || (i == MAX_REP_LECTURA));

/*
      0-10 Saturated Soil. Occurs for a day or two after irrigation
      10-20 Soil is adequately wet (except coarse sands which are drying out at this range)
      20-60 Usual range to irrigate or water (most soils except heavy clay soils).
      60-100 Usual range to irrigate heavy clay soils
      100-200 Soil is becoming dangerously dry
    */
    result1=constrain(value1/(AGUA_DIR-AIRE_DIR)*100.0, 1, 100);
    result2=constrain(100-(value2-AGUA_INV)/(AIRE_INV-AGUA_INV)*100.0,1,100);
    resultp = (result1+result2)/2.0;
    resultcb = resultcb + constrain(square((-2.96699 + 351.395/resultp)),0,200);                           //Equation fit using stat software
    count++;
 
    //Send the data - only if moisture changed to save battery (send anyways once every 4 readings). If moisture sent, send battery level.
    if ((oldresultcb!=resultcb) || (count==MAX_REPORTING_LOOPS)) {
      send(msgmoist.set((unsigned int)resultcb));
      oldresultcb=resultcb;
      //Measure battery voltage and send level
      float v = vcc.Read_Volts(); 
      int p = vcc.Read_Perc(VccMin, VccMax);
      p=constrain(p,0,100);
      sendBatteryLevel(p);
      #ifdef MY_DEBUG
        Serial << "Value1=" << value1 << " " << result1 << endl << "Value2=" << value2 << " " << result2 << endl << "Result = " << resultp << "% (" << resultcb << "cb)" << endl;
        Serial << "VCC = " << v << " Volts" << endl << "VCC% = " << p << " %" << endl;
      #endif
    }
 
    if (count==MAX_REPORTING_LOOPS) count=0;
    //sleep(SLEEP_TIME_3h, true);
    sleep(SLEEP_TIME_15min, true);
  }
}

Als Reading bekomme ich folgendes angelegt:

READINGS:
     2019-03-16 14:19:53   SKETCH_NAME     Sensor de humedad
     2019-03-16 14:19:53   SKETCH_VERSION  3.0
     2019-03-16 14:19:54   batteryPercent  36
     2019-03-16 14:19:54   level1          200
     2019-03-16 14:19:53   parentId        0
     2019-03-16 14:19:54   state           asleep

Im Serial Log sieht alles soweit gut aus und die Daten sind erstmal plausibel.

Gruß

Markus

Beta-User

Moin,

da MySensors intern bei der Kommunikation zwischen den Nodes und dem GW "nur" Ziffern verwendet, die für bestimmte Datentypen usw. stehen, werden die durch die Module nur wieder rückwärts in Text "übersetzt"...
Die Ziffer hinter dem Typ ist dann die ChildID.

Das ist das ganze "Geheimnis". Hat also nichts mit der Presentation zu tun, sondern "nur" was damit, was dann im laufenden Betrieb gesendet wird.

Oder war die Frage anders gemeint?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Markus.

nee danke dir das hilft schon weiter... :-)
Also ist im MySensors Modul eine Art Lookup table wenn ich das richtig versteheund ich muss im Serial log schauen welche "Nummer" zu welchem Datentyp passt für folgendes..


MyMessage msgmoist(CHILD_MOIST_ID, V_LEVEL);


Und in der Mysensors.h müsste dann auch das "reverse" zu finden sein, also Datentyp -> Ziffer

Gruß

Markus


Beta-User

lookup-table trifft es ziemlich gut.
Die ganzen MySensors-fhem-Dateien sind eigentlich ein lookup-System von Tabellen und Arrays mit recht wenig Perl-Code dazwischen ;D .

Eigentlich müßte dir erst mal ein Blick in die constants.pm (im lib-Verzeichnis) reichen und MYSENSORS_DEVICE am Anfang, das ist spiegelbildlich zur MySensors 2.0 API...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Mathea

Hallo,

ich finde das ist eine ziemlich interessante Diskussion. MySensors bietet ja die Möglichkeit, noch einen beschreibenden String pro Presentation-Message mitzuschicken. Im MYSController wird dieser String auch zu den jeweiligen Child-IDs hinzugeschrieben. Wäre es möglich, diese Funktionalität auch in das FHEM-Modul einzubauen? Im Moment habe ich einige MySensors Geräte, die viele Child-IDs haben. Das macht es in FHEM relativ unübersichtlich, da ich mir immer merken muss, welche Nummer noch mal für welche Message steht. Wenn dieser Description-String direkt als Reading-Name eingetragen werden würde, hätte man dieses Problem nicht.

Viele Grüße,
Mathea

Beta-User

 :) Schau mal in die cref und das letzte größere update...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Markus.

Ich glaube ich muss mir die ganzen Zusammenhänge beginnend von Presentation im Sketch, der Wertzuweisung und der entsprechenden Weitergabe mal ansehen um das zu verstehen.. ;D

Gruß

Markus

Beta-User

M.E. geht das am einfachsten mit dem Modulcode innerhalb von FHEM selbst. Die einzelnen Funktionen sind entsprechend benannt (onPresentationMessage() usw.). MYSENSORS stellt dabei immer erst fest, welchem DEVICE eine Nachricht gehört und ruft dann dafür die entsprechende Funktion in DEVICE auf. Das ist "eigentlich schon alles"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Markus.

#8
so ganz steige ich da noch nicht hinteraber ich glaube ich weiß nun warum diese "nicht passenden" Readings angelegt werden.
Das Problem habe ich ja mit diesem "Soil Moisture Sensor". Ich sag mal das original verwendet ja den Digital Input. Da machen die Readings ja auch Sinn.
https://www.mysensors.org/build/moisture
Jetzt mal los gelöst von der Tatsache, das der Sketch auf dieser Seite ganz und gar nicht zu dem Verkabelungsschema passt,
lese ich ja einen Wert über einen Spannungsteiler an A1 aus, also Analog.
Presentiert wird das ganze im Sketch als

present(CHILD_MOIST_ID, S_MOISTURE, "Feuchtigkeit Boden");

Was ja (nach meiner Logik ;-) ) zur Folge hat, das folgende Readings angelegt werden. Was ja auch geschieht

S_MOISTURE              => { receives => [], sends => [V_LEVEL,V_TRIPPED,V_ARMED] }, # Moisture sensor

Das heißt für mich die Presentation ist insoweit falsch, den sie verwendetet einen falschen Sensortyp in bezug auf die Auswertung des Analogen Signals.
Stimmt das soweit oder ist das totaler Quatsch?

Gruß

Markus

Beta-User

Ohne mich mit dem Sketch auseinandergesetzt zu haben:
S_MOISTURE              => { receives => [], sends => [V_LEVEL,V_TRIPPED,V_ARMED] }, # Moisture sensorhat "nur" zur Folge, dass bei der Anlage des Devices in FHEM (bzw. bei neuen Presentations, wenn neue Children dazukommen oder sich die Nummerierung geändert hat usw.) einige default-"Variablen" bei dem Device angelegt werden, z.B., dass für "set"-Anweisungen eben on/off oder Textfelder verfügbar sind, wenn bei "receives => [xyz]" steht.

ABER: Innerhalb FHEM ist das keine wirkliche Begrenzung. Man kann das setReading auch händisch anlegen und die selbst definierten dann "ganz normal" weiter verwenden.
Auch was Readings angeht, die generiert werden, weil die Node irgendwas sendet (sends => ...), ist das keine effektive "Begrenzung". FHEM wird also z.B. auch ein Reading "temperature233" anlegen, wenn du jetzt ganz ohne "presentation" auf die Idee kämst, irgendwo im Sketch unter der ChildID 233 einen Wert unter Verwendung des Temperatur-Typs zu senden...
Andere Controller verhalten sich da ggf. anders, aber FHEM ist das ganz egal ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files