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
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?
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
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...
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
:) Schau mal in die cref und das letzte größere update...
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
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"...
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 (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
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 .