yea i ended up using V_VAR1 - V_VAR5, V_CUSTOM, V_TEXT and presenting both S_INFO and S_CUSTOM.

i am currently reading it through Wemos D1 Mini + MAX RS485 converter (working without logic converter just fine).

This sounds silly but it really annoys me.

I switched from OpenHAB2 (using MQTT binding) to Home Assistant (using mysensors component) to read my Energy Meter (SDM220) which has a total of 14 variables that are read via Modbus RS-485 according to the manual.

i do present both S_POWER and S_MULTIMETER, but i do not present the rest (frequency, phase angle, total Kvarh, etc) because there is not proper sensor type (V_*) to represent them.

i've allocated the number 57-63 to send the rest of the data, but home assistant component is complaining that they're undefined in the dictionary.

V_VAR1 - V_VAR5 are not enough for me, and i really don't want to break them to multiple child nodes, has anyone considered adding S_ENERGYMON (that would include all values -existing and non-existing- under it) ?

Try DI00 -> D4 (see attached)

i remember altering something in the .h file of RFM69

#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 0

try making both 2, or both 4

@Jic i was wondering what's the purpose of the 1 M resistor on the reed switch ?
i used 2 x AA battery, digitalRead, 8 MHz stock clock and no resistor, i know this might not be the most optimized power consumption setup

i don't why, but debouncer.read(); always return 1, i was never able to send the status of the door, however, digitalRead(BUTTON_PIN) returns the actual value.

since i am using this for reed switch, i believe i don't need the debouncing functionality do i ?

@Yveaux one last, i promise :P

if max battery voltage is actually 3.2v, does that mean that the battery percentage would show 100% for quite sometime before it starts dropping below 3.0v (assuming vmax is set to 3.0) ? or would it increase the inaccuracy gap ?

@GertSanders thanks , i think accuracy isn't a deal breaker, i believe everyone's concern is to just know when the batteries need to be replaced (hopefully that can be done without specifying the voltage correction).

@GertSanders sorry mate, am more of a software guy..

according to the lib i've seen and @Yveaux's example for the internal method, at the begining you need to define a corrective value :

const float VccCorrection = 1.0/1.0;  // Measured Vcc by multimeter divided by reported Vcc

Vcc vcc(VccCorrection);

is this necessary for an accurate reading ? and is the corrective value need to be just entered once (like a calibration per arduino) or need to be reconfigured every time you replace a battery ?

@GertSanders following the instructions of this post suggest using Alkaline batteries (apparently Li-ion aren't a good idea for sensor nodes ?! plus they are expensive), the optimal solution would be using 2 x AA batteries as some ans this post suggested.

I believe there is no way 2 x AA batteries in series would measure anywhere near 3.3v, the max i measured with brand new batteries was 3.2v.

my major concern is:
would i still need to the do the voltage corrections when using the voltage divider ? if so, does that need to be reprogrammed every time you replace the battery ?

sorry to bring this again @Yveaux @axillent

i just want to get this once and for all, so others coming by gets it directly instead of going through all the 2 threads posts, please correct me if i am wrong:

1- using the voltage divider is needed if there is a voltage regulator / booster where where VBatt != Vcc.
2- using the voltage regulator is not needed if the voltage regulator is removed / no booster is used (powering directly from 2 x AA batteries) where VBatt == Vcc.

*I've noticed the 2nd method requires inputting battrie's DMM measured values vs arduino ones for correction, is this a down side if you need to change the battery later on ? or is it just programmed once ? and does the 1st method rquirs these corrections too ?

Cheers

to avoid complixity in Openhab (or any other controller not supporting null as a valid data type), it would be a good idea to overload the request function to have a non empty payload, in order for those controllers to accept the request and provide the value

by hek:

This PR was merged a few days ago:

https://github.com/mysensors/MySensors/pull/633

great ! glad to find someone thinking the same way :)

is there a newer release of the lib soon ? or shall i manually download it and install it ?

so probably before processing the incomingMQTT, subtract the whole string of the incoming prefix and then start processing.

i had my MQTT incoming prefix defined as

#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "meshx86/ndw/pir_dht/in"

the void receive() function won't be triggered if the MQTT path for incoming messages has '/' or '-' in it, as it would be interpreted as a wrong message maybe ?!

note: i was able to successfully have have in the console message arrived with the above prefix, it is probably the slashes and dashes confuses the MQTTClient gateway

@Meshx86 i figured out the problem which i believe it is a bug, you can't have in your incoming MQTT prefix "/" or "-" in the path, otherwise the message won't be parsed properly

I've seen the relay sketch which has a receive function but that is for Radio Nodes, i was wondering about processing arrived MQTT messages to the MQTTClient gateway so it changes a variable / acts on a relay.

is there any way to do that ? is it using the receive function as well ?

note: i've already defines a message that has the V_type and CHILD_ID matching, i've got the message on the gateway console, i was wondering to get it into a variable.

Thanks

can Li 18650 3.7 batteries be used as they are rechargeable ? knowing the max voltage at full might reach 4.1-4.2v ? maybe keeping the voltage regulator ?

@Martin-Tellblom cheers

I have the following setup:

1. MQTT Gateway on Wemos D1 mini (ESP8266)
2. Node on Arduin pro mini

i can't get the openhab binding to distribute address to the nodes, in things in openhab there is no option for MQTT Gateway to add, what is the procedure ?

Cheers