@gieemek If You are talking about ack parameter of the send function then it is not what I'm talking about. I'm talking about this:
https://github.com/mysensors/MySensors/blob/aa76d266159d87cd460597657ac7f669a706fad5/hal/transport/RS485/MyTransportRS485.cpp#L243
on line 245:

	(void)noACK;	// not implemented

I newest API version 2.3.1 send function has parameter named echo instead of ack which makes easier to distinguish beetween transport level ack and protocol level echo request.

Hi all,

I see that there is no ACK functionality implemented for RS485 transport and I did first try to implement it. I'm wondering if there is someone on the forum that in some way is maintaining codebase for the RS485 transport and could look at it.

@tekka
Is there something I could help to spped up merging STM32duinoUpdate branch into master ?
At the moment I have couple of blue pill boards (STM32F103C8) and want to test RS485 network with MySensors.

And that I have one question, Is it possible to use two hardware serial ports - one for rs485 and another for debug prints ? What I tried is:

• using AltSoftSerial for rs485 but STM32 platform is not supported there
• using #define MY_RS485_HWSERIAL Serial1 and #define MY_DEBUGDEVICE Serial2 but Serial2 does not exist
• using SoftwareSerial but it seems that the code hangs somwhere and does not even get into setup() function (SoftwareSerial uses some timers so maybe they interferre with MySensors)

Hi,

I'm trying to build dust sensor node powered with li-ion battery. Actually I already built it, but i'm not satisfied with how long it runs on battery. The problem is that according to the specification, the PMS7003 needs about 30 seconds after wakeup to give realiable results, and during this 30 seconds the node is consuming around 80mA of current which is a lot. I'm taking measurements every 10minues so according to my calculations the mean current is around 4mA. Between measurements I disable power for the PMS7003.
So my question is: are there other scenarios for using PMS7003 with battery that would make the node run longer on single recharge ?

looking at the code it seem that calling wait with small wait value would do the job, but is there more explicit way ?

Hi all,

I think that my node has to much stuff to do in single iteration of the loop. I would like allow mysensors to kick in in between processing different parts of my node. Is it possible ? Is there some MySensors function I can call to force processing of incomming messages ?

@lood29 MLCC

@yveaux one capacitor was on the bme280 module from aliexpress, but other two are samsung capacitors bought from big european seller (tme.eu).

Hi all,

I want to share with You my issue I had with couple of my battery powered sensor nodes. They are build on atmega328p + RFM69W. They were working perfect for over a year consuming low power. But then, one after other started to consume much more current. It turned out to be a failed power decoupling capacitors. When I replaced them the current consumption went back to normal level. The failed capacitors measured with the ohm meter reported low resistance, like less that 10kOhm or even less that 1kOhm. Has anyone encountered such a problem ? it was three capacitors in three different nodes, so it's like 5% of all capacitors in all my nodes :) It would be bad if I would need to resolder those capacitors every year ...

@thenounoursk I really advise You to get a good multimeter with current measurement down to 1uA. Without it You will have hard time to debug problems with high currrent consumption. And I mean high current is about 100uA for a battery powered node. Waiting couple of days to check if current cosumption problem is fixed is not a good idea :) There can be a lot of issues that makes your node consume to much current, both hardware and software. For example, I have a node that had good current consumption, but after some time it started to cosume much more current. It turned out to be a failed power decoupling capacitor. Without multimeter I would never find out what was the cause.

@sergio-rius said in Build retry funtionality into the mysensors library:

How MQTT qos 1 does? I think it should be similar to it.
Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.

But MQTT broker is not running on the 1kB ram mcu. Having lots of memory available it is not a brain teaser to implement such functionality. For a small mcu You have to make some compromise. In one case droping messages is completely ok, but for other is not. It may turn out that there is no ONE algorithm that will fit all cases ...

@mfalkvidd said in Build retry funtionality into the mysensors library:

(No exponential backoff)?

its expotential, but no more than hardcoded value (don't remember what value)

@mfalkvidd said in Build retry funtionality into the mysensors library:

I guess some sort of timestamp when the last send attempt occurred, and a retry counter is needed to be stored per message as well?

Yes, could be useful for debugging purposes. In the ideal setup retry counter should be always 0 :)

@mfalkvidd I believe that my code have a lot of room for optimisations. From the ram perspective having multiple union structures that can hold also text up to 32 chars (?) is not optimal. One way of optimising the ram usage would be to keep one MyMessage instance, and initialise this message just before sending it with a required value. This way the ram usage would be 1 MyMessage + sum(sizeof(value) for value in sensor_values) where sensor_values are current sensors/actuator readings.

@mfalkvidd said in Build retry funtionality into the mysensors library:

Do you statically allocate the ram needed to store the transmitted values, or are you able to do it dynamically without causing fragmentation?

For example You have a node with two sensors, then there are two MyMessage objects defined statically.

How much extra ram is required?

The size of MyMessage for every message :)

Is there support for larger messages, such as V_TEXT?
To My knowledge in MySensors there is only one size of MyMessage object which is a union of multiple represenstations of the message content and the size of MyMessage is MAX_MESSAGE_LENGTH. So I don't understand the question :)

How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?

The last value of the actuator is taken. You can imagine that there are two threads. First is setting the atomic value shared between threads, and second is reading this value and sending it to the gateway. If first thread writes two times before second thread sends first time, the first value is not sent.

My approach is memory hungry if there is a lot of distinct values to send to the gateway. May be it could be improved to reuse single message in the background.

One important thing is that there is a differenc in approach to battery powered (sleeping) nodes and powered nodes.
In powered nodes, there is not problem going to forever loop trying to deliver message to the gateway.
My algorithm is essantial for battery powered nodes, where banging messages in forever loop will drain the battery quickly if for example gateway goes down for a while.

You can look into my code here:
https://github.com/mczerski/MySensorsToolkit - this is the toolkit library with all the logic implemented
https://github.com/mczerski/MyMultiSensor

• this is example use of the toolkit library

@alowhum this is (almost) exactly how I setup my MySensors network. The only difference is that I rely on "hardware" ack (the return value of the send function) and do not have any repeater nodes in my network - this prevents message flood on the network.
This approach works quite well.

@mfalkvidd
"I am not sure how retrying even more times will help anything. Retrying more times could destroy user experience, since the node would seem to be frozen (not responding to input) until a message is eventually decidedly delivered."

Retry mechanism should be implemented in a non-blocking way. I implemented it in a way, that every sensor/actuator has statically defined message and handling of sending/retrying of this message is done in the "background" in non-blocking manner. one call to send in every master loop iteration, and the result of the send is stored between loop iterations.

Not doing retryies until the message is sent is very bad idea.
For example, You have a remote button that will toggle play/stop of your music player. Between button press and music starting to play there is some time, like 5 seconds. If the messege from button does not reach the gateway, the user will realise this after something like 10 seconds. This is not acceptable. The button should banging the same message over and over until it reaches the gateway - this is the only think that this button does and it should do it 100% realiable (I'm not counting hardware failures here).

@alowhum said in Everything nRF52840:

Can these Arduino's even present themselves as a specific Bluetooth profile? E.g. as a bicycle cadence sensor, or a smart lamp, etc.

Bluetooth profiles are nothing more than just a set of rules how to structure software ofluetooth profile means that your device provides attributes to read/write described in that specific profile. You can present your device as specific prfoile but not implement its requirements, but in that case other devices will not work properly with yours. So the answer is yes - its just the mater of the software.

@danielo-rodríguez I would argue that this approach has better better parformance in terms of battery saving. The PIR must be powered all the time and it consumes an order of magnitude more current than the sleeping MCU. In MySensors, when the node is sleeping and it wakes up to send a report to the controller, it sends just one message. But when the node is starting from poweroff it sends multiple messages like presentation etc. This would for sure cause actually more battery drain than the sleeping node. Propably You could design a protocol in which the node just sends a single message after power on, but I don't know if it is possible with MySensors. Implementing Your own protocol just to fit this wierd setup sounds like a really bad idea. The other issue with using PIR as a power on/off to the MCU is reporting that the PIR is no longer detecting motion. When PIR output goes off, the MCU also goes off and You cannot send the report to the controller. How You would solve that ? You would need some king of timing circuit that will hold on the power for some time. This just adds complexity to the design and probably the power consumption which after all is the thing You want to imporove instead of make worse.

@danielo-rodríguez using interrupts is the normal way of handling such sensors and both the PIR and MCU are design to work this way. Doing it the other/wierd way is asking for trouble. What problem You want to solve by powering off the MCU ?