Posts made by rozpruwacz

@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 ?

@yveaux how frequently the battery must be replaced ? and what kind of battery it has ?

Check this one: http://linuxgizmos.com/linux-driven-sbc-costs-6-or-8-with-wifi/
It has betterl mainline linux support and the ARM core is newer and faster and has more RAM.

use negation operator.

@lood29 encryption is not authentication, these are different things

@dk_iot to my knowledge MySensors runs only on Arduino platform (and not even every arduino). MySensors gateway also runs on linux.

Maybe spi wiring to the ethernet module od bad ?

@masmat Check if You can connect to the broker from another computer. Check if You can ping your gateway from another computer.

@franz-unix said in Pir AS 312 with 2 rechargeable AAA battery. Boost needed?:

About the Li-ion battery, it seems to be a general agreement (see this topic for example) about the fact that the best option to power a node is with AA or AAA batteries. In fact one of the advantages is that you don't need to step up or down the voltage to power the radio and the MCU.

There is no one "best option". The power supply heavily depends on the project requirements. The PIR sensor requires noiseless voltage between 2.7 and 3.3v. This makes use of 2xAA problematic. In my opinion for such a project higher voltage supply with low quiescent current ldo is the best option. And it happens that li-ion battery with its voltage range and 3v ldo makes them perfect match. At least this is how I did it in my home and it works nice ( https://www.openhardware.io/view/610/MySXMotion). I went even further in my project and there is two ldos, one for pir and one for mcu + rf module as those two components creates large spikes in current flow as they work making supply voltage noisy.

PS. The other benefit of rechargable batteries is that they are rechargable so you don't need to remember to buy batteries when you go out of them.

@franz-unix if the ME2188 was really low noise and low ripple it would be good idea to use it. Unfortunetely there is nothing about it in the datasheet axcept for manufacturer declaration ... no data to support this declarations so it sounds rather not convincing. But if You have time to test it go for it

@franz-unix i don't know how you will handle the pir in your software but generally the pir needs to be powered all the time so no need for shutdown mode in your boost converter. The other thing is that pir doesn't linke noisy power supply, and dc converters are rather noisy especially in low current area. I would recommend to use higher voltage and ldo voltage regulator. You can find some ldos with very low quiescent current. You can use li ion rechargable battery and 3v ldo.

@heinzv said in stm32 sleep support:

But the main question is: Have you found cheap maker boards with such mcu's like STM32L4S5 or STM32L4R5?

For me it is not the main question. Simply because there is no board that will fit all my needs regarding peripherials, size and shape. So for every project I need to design my own board, so it does not matter if there is a cheap maker board or not. Besides I do not recall any nrf52 maker boards that are cheap. Certainly You cannot call a maker board those small smd modules from aliexpress - they all required some kind of motherboard.

And stm32 mcus has very wide peripherial and memory options. For example stm32l4+ is up to 2MB flash and 640kB sram. So it is twice the amount of memory in nrf52840.

@heinzv as i wrote before there are other transports than just nrf. There is wired rs485, lora rfm95, and for those like me that live in a bunker the 2.4ghz band has very poor range so the 868mhz rfm69 is the solution. So there is plenty reason to not use nrf5 and for those cases stm32 is quite a good choice.

@nagelc AFAIK stm32L chips are pin compatible with stm32F, so all it takes is to desolder F chip and solder L chip. plus of course the cost of the L chip.

@monte I sniffed a little bit the topic and it seems that the first step would be to move to the Arduino_Core_STM32 from stm32duino github project (not the stm32duino.com on which mysensors is based). I don't know how those two projects relate to each other but for sure they are different project and have different API ... The github one supports a lot more stm32 devices inclueding stm32L The second step would be to use STM32LowPower library form the same github user to implement sleeping.
I could try to port mysensors to this new arduino core but as I wrote before I have not much spare time so it may take a long time.

I understand that there is no active developement in stm32 area Unfortunetely I do not have time to maintain such a project but for sure I can help with testing.

Hi,

yesterday I was playing around with blue pill board to see how it goes with MySensors. To my amazement I discovered that the sleep functionality is not implemented for stm32 architecture are there any plans to support sleeping on current stm32 implementation ? And also are there any plans to support stm32L devices ? I think that stm32 devices are very interesting for MySensors projects. I know that now the NRF5 architecture is on the top priority, but there are other transports like RS-485, RFM69 etc. that could realy benefit from using arm based MCU. I realy love how different stm32s are pin compatible between different families. For example I could use stm32f103c8 in lqfp48 package in my next project, and when the stm32l1 support comes in I just swap it for stm32l151cc and voila, now I have ultra low power node But before I go into stm32 I would like to hear from project maintainers if there are plans to actively support stm32.

I was reading through the BLE5 specs and I got an impression that this standard is so complex that it would be really hard to make ble5 network reliable ... and it is still 2.4GHz but I think that it may be the future of smart home.

try MyController, it works on linux. You can even run it on rpi, but I would not recommend it since it is quite resource hungry.

@huex try with new battery

Hi feanor-anglin,
Did You considered powering the node over the rs-485 bus ? I found this paper (http://www.ti.com/lit/ug/tidu993/tidu993.pdf) that describes how to do it. It seem quite simple and I think that it would make the wiring much simpler (no need for PSU for every node).

@omemanti said in nrf52832 sleep power consumption:

am612

hmm, according to am612 datasheet the pir itself consumes around 15uA, so I would say that You have much better sleep current. Can You share your sketch ?

What is expected power consumption of the nrf52832 chip when sleeping with MySensors library ? My measurements shows around 17uA @ 3.3V. For the reference I flashed some dummy program with just __WFE call and the current consumption is around 1uA.

@neverdie i'm comparing it with core51822 module which also has pcb antenna

@neverdie said in Everything nRF52840:

@rozpruwacz No, I hadn't noticed that. Do note though that you can increase the tx power on the nRF52840 dongle to 8db, whereas 4db is the max for the nRF51822.

Yes, but with the same settings I would expect at least the same range. I will keep testing.

@NeverDie did You compared somehow the range of the nrf52840 dongle with other nrf52840/nrf52832/nrf51822 modules ? I'm asking because after first test it appears that the nrf52840 dongle has worse range than core51822 module using the same radio settings.

so I got my nrf52840 dongle I was able to run mysensors node and serial gateway using MyBoardNRF5 nrf52832 board. So far so good I was also able to upload the sketch using usb dfu, it required minor changes to the linker script although.
But from the first tests it appears that the range of the nrf52840 dongle i less than the nrf51822 board I was using before

@артем-тихонович the 3.4 kernel is the "legacy" kernel and is not compatible with mainline kernel. I would suggest to install os with the mainline kernel. Otherwise you need to change mysensors code.

@артем-тихонович which os with which kernel version do You run on the cubieboard ?
check if You can do this in the console:

echo 1 > /sys/class/gpio/export
cat /sys/class/gpio/gpio1/direction

there may be also permission problems so try also as root

I have a small update for those who follow this thread. So I bought tje st-link v2 programmer and the only [nrf5 board](https://www.waveshare.com/wiki/Core51822. .com/wiki/Core51822) that was available in my country (Poland). This was only to get used to nordic environment. So With this setup I was able to run nrf51 sdk examples and MySensors examples without any problems. For MySensors I just followed this. And for compiling and uploading nordic sdk I used GNU MCU Eclipse. I was very suprised that this eclipse plugin works so well, no problems at all. And the latest eclipse cdt has suport also for arduino so I could compile and run MySensors code also from eclipse As far as I used it, the Arduino support in eclipse lacks only importing example projects, "burn bootloader" and "Upload Using a Programmer" tools. Oh, and the serial monitor in eclipse does not have any settings for adding cr at the end of line, so MySensors debug log is not readable.

Regarding nrf51822 board, it has much better range that nrf24L01+ that I used before. But it is not good for sleeping MySensors nodes due to high current consumption when waiting for gpio interrupt. It could be fixed by changing the nrf5 mysensors implementation to use gpio port event just like in nrf51 sdk examples - this applies to all nrf51822 boards. And the board I have lacks inductors required for low power dcdc setup.

And now I'm waiting for my nrf52840 dongles

ok, so I understant that You wan't to use sleep functionality after all. You just wan't additionally to be able to cut off the power totally. So I see couple of problems with that:

1. You will not be able to precisely keep track of the window state, unless you will send KEEPUP messages every couple of seconds which will make your node more power hungry.
2. Be aware of battery self discharge. According to wikipedia the 9v alkaline battery will self discharge after 5 years. And it is very easy to make a window sensor that will last 5 years. So I do not see any benefit here.

If you realy want to add power cutoff to your design I would suggest to add some large capacitors that will hold the charge long enough after power cutoff to send an "off" message to the controller.

Ok, so nrf52840 dongle seems like the best solution.

@alowhum yes, probably i just don't understand what you trying to do. What is "sipping"?

@neverdie said in my first nrf5 ... NRF51/NRF52 which is better for MySensors ?:

another

i'm confused I asked about it but did not received an answer. Is nRF52840 supported by MySensors ?

@alowhum You say You are giving workshops to people and You don't have an idea on the topic ? Sorry for the language but this sounds ridiculous ... Handling of the interrupts is the most basic concept of the microcontrollers. Do not teach people doing stuff in the wrong way please. You want to change gateway controller and in the same time You say that You are "not good enough at programming". It sounds contradictory. To use sleeping node is much easier to do in comparison to changing the gateway code. I would even argue that doing what @frits suggested is easier than Your idea. Your idea is wrong in every possible way. For example, the power consumption in Your case will depend on the time the window is opened, so if someone prefer to have opened windows, then in his case the node will drain the battery pretty fast.
I hope that You will not feel like I'm attacking You I just want You push to the right direction.

thank all for the replies. I know that the nrf52840 is the best when concidering the hardware, but according to this:
https://www.openhardware.io/view/376/MySensors-NRF5-Platform
it is not supported by MySensors. Is it still true ?
I started this thread because sadly I just don't have anymore the time to do any research and hacking. What I want to do is to buy some relatively cheap boards that I don't need to solder any additional components, upload some example MySensors sketches and see how it works (mainly to compare the range to nrf24 and rfm69). So smd modules are no good for me, but if there is some "motherboard" or expansion board it may be enough.

@wassfila do You know any cheap, prototyping friendly nRF52840 boards ?

@nca78 ok thaks, so in Your opinion does the module I linked is good for testing/prototyping nrf5 MySensors nodes ?

@nca78 said in my first nrf5 ... NRF51/NRF52 which is better for MySensors ?:

In terms of "low power" there's a significant improvement in transmit/receive power, and if you can transmit at 1M instead of 250k for the same sensitivity budget it means you need to transmit only 1/4 of the time, big improvement... With only 50% of sleep power also, there's no comparison NRF52832 is much better.
NRF51 also have some limitations in terms of interrupt, it's a problem for low power nodes as over one interrupt you have to make relatively complex tricks to keep very low power in deep sleep.

Ok, so the winner is nrf52832

regarding the low frequency oscillator, here it is written in the "Buying guide" section that "If you plan to make a battery powered sensor, you should choose a module including the low-frequency oscillator (32,768kHz) for precise low power sleep modes". So this is not true as the LF clock is not used by MySensors ?

Hi,

I'm looking through datasheets and it seems like there is not so much difference between the two. Of course the nrf52832 has more peripherials, memory and is a little bit more low power but those aspects are not so important for my use case. So what would make nrf52832 better for mysensors ? The nrf52832 has -96dBm sensivity at 1Mbps data rate (and do not have 250kbps data rate) and nrf51822 also have -96dBm sensivity at 250kbps data rate. Both have +4dBm transmit power. So for me it looks like if there is no peripherials or memory limitations both chips are equally good for MySensors network.

Oh, and could it be used as a gateway also ? I read somewhere that for low power nodes the low-frequency oscillator should be choosed and for normal nodes the high-frequency crystal should be should be choosed. So it seems like the hardware for low power node cannot be also used as a gateway. Is it true ?

Hi,

I want to start using nrf5 with mysensors. I'm looking for some easy to use nrf52832 modules that does not require much external components (if any). I found this:
https://pl.aliexpress.com/store/product/Nordic-nRF52832-module-Bluetooth-low-energy-development-board-for-BLE-mesh/420533_32867403706.html?spm=a2g17.12010612.8148356.6.71c7caa2i1bdWy

Is it good for use with battery powered node ? I'm not sure but it has the 32kHz oscilator and inductor for low power mode. The module exposes swdio ad swdclk pins for programming so it can be programmed with cheap st-link v2 compatible programmers ? I would like to power it directly from coincell battery. So after connecting just a battery could it already talk with other mysensors nodes ?

@crankycoder use 3v ldo istead of 3.3v ldo. Evereything will work at 3v without problems and you get almos full battery capacity.

@alexvanbelle what is your configure options? And what is i2c used for?

@alexvanbelle Well, I forced it really hard by modifying the code in drivers/Linux/Arduino.h in line 35 there is an ifdef that decides what to use for GPIO. For RPI case the RPi.h is included instead of GPIO.h, so I just reversed the if, this is the patch You can apply to MySensors:

diff --git a/drivers/Linux/Arduino.h b/drivers/Linux/Arduino.h
index eb9ee38..9592919 100644
--- a/drivers/Linux/Arduino.h
+++ b/drivers/Linux/Arduino.h
@@ -32,7 +32,7 @@
 #include <algorithm>
 #include "stdlib_noniso.h"
 
-#ifdef LINUX_ARCH_RASPBERRYPI
+#ifndef LINUX_ARCH_RASPBERRYPI
 #include "RPi.h"
 #define pinMode(pin, direction) RPi.pinMode(pin, direction)
 #define digitalWrite(pin, value) RPi.digitalWrite(pin, value)

I run mysgw with gdb and for me it segfaults when trying to access gpio:

(gdb) run
Starting program: /usr/local/bin/mysgw 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Sep 29 13:04:51 INFO  Starting gateway...
Sep 29 13:04:51 INFO  Protocol version - 2.3.0
Sep 29 13:04:51 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,VER=2.3.0
Sep 29 13:04:51 DEBUG TSF:LRT:OK
Sep 29 13:04:51 DEBUG TSM:INIT
Sep 29 13:04:51 DEBUG TSF:WUR:MS=0

Program received signal SIGSEGV, Segmentation fault.
bcm2835_peri_read (paddr=0x7) at drivers/BCM/bcm2835.c:123
123			ret = *paddr;
(gdb) bt
#0  bcm2835_peri_read (paddr=0x7) at drivers/BCM/bcm2835.c:123
#1  bcm2835_st_read () at drivers/BCM/bcm2835.c:1126
#2  bcm2835_delayMicroseconds (micros=1) at drivers/BCM/bcm2835.c:449
#3  0x0002ce5c in BCMClass::digitalWrite (this=<optimized out>, gpio=<optimized out>, value=<optimized out>) at drivers/BCM/BCM.cpp:62
#4  0x0002d7ac in RPiClass::digitalWrite (this=<optimized out>, physPin=physPin@entry=24 '\030', value=value@entry=1 '\001') at drivers/BCM/RPi.cpp:56
#5  0x0001c22c in hwDigitalWrite (value=1 '\001', pin=24 '\030') at ./hal/architecture/Linux/MyHwLinuxGeneric.cpp:158
#6  RFM69_initialise (frequencyHz=868000000) at ./drivers/RFM69/new/RFM69_new.cpp:206
#7  0x00020da4 in transportInit () at ./hal/transport/RFM69/MyTransportRFM69.cpp:26
#8  stInitUpdate () at ./core/MyTransport.cpp:100
#9  0x000258a4 in transportUpdateSM () at ./core/MyTransport.cpp:384
#10 transportProcess () at ./core/MyTransport.cpp:464
#11 transportWaitUntilReady (waitingMS=0) at ./core/MyTransport.cpp:453
#12 _begin () at ./core/MySensorsCore.cpp:155
#13 0x00012f2c in main (argc=1, argv=0x7efff4c4) at ./hal/architecture/Linux/MyMainLinuxGeneric.cpp:447

On RPI platform the gpio kernel driver is not used, instead gpio is accessed with mmap :(. When I forced the build to use gpio kernel driver all works without problem when running as non root. So maybe the solution should be to add configure option for rpi to use gpio kernel driver ?

@dell640 said in RFM69HW RSSI / range problems:

Can somebody local, with good working RFM69HW module confirm, that his values of RSSI in CSMA routine are usually below -95?

Yes, if You have properly designed your node/gateway. I had exactly same problem when I was powering the rfm module from 3.3v pin of the rasberry pi. Using separate LDO for the rfm module reduced the RSSI values to around -100dBm. Use low noise LDO, keep power paths short and use decoupling capacitors and it should make things better.

I have implemented it in form of library. The library is here https://github.com/mczerski/MySensorsToolkit and example project that uses this library is here https://github.com/mczerski/MyDimmer. The actual logic is implemented here https://github.com/mczerski/MySensorsToolkit/blob/master/src/MySensorsToolkit/Message.cpp

This implementation is not using software ack because i do not use repeaters in my setup and i believe that for such setup software ack will make no difference.

@freynder yes, the lower the better. You may be confused by this because the rssi is "Received Signal Strength Indication" so the higher the better, but in this function this indicator is used to check that nothing is receiving

@freynder no, the function is correct. Before sending the rssi value read by this function should be lower than treshold -80dbm is not lower than - 95dbm. You should get rssi reprted around - 100dbm in this function but for some reason you have higher values.

I had similar problems. What is happening is the rfm69 drivers is checking the rssi value before sending anything. If rssi is below some treshold the mesage is sent, and if not the driver waits 500ms and then it sends the message regardless of the rssi value. When message is send, the driver waits only 200ms for the ack, so if other end has high rssi value the ack is not received on time. So the problem is high rssi value before sending. In my case it was due to poor power supply so i would recommend powering the rfm module from separate low noise ldo regulator.

@556duckvader i'm using bme280 module with regulator but desoldered the regulator and i power it from the same 3v that the atmega is powered. All works fine.

Hi,

I was thinking about message delivery quality in MySensors network. It is pretty easy to make sure that the node will deliver message to the gateway by sending it over and over until the ack comes back. The node has limited (and known) number of messages it can send, they may be statically defined. This makes it easy to implements such assurance on the node side. But on the gateway side it is not so easy, because the gateway would need to dynamically track which messages got acks and wich not. BUT, there is mqtt which solves that problem for us. What if a mqtt gateway would implement the qos > 0 in such a way that when gateway do not receive ack from the node it would not inform the mqtt broker that it received the message ? It would pass the whole logic of resending message to mqtt broker which propably run in much less constrained environment.

there is MCU onboard, it is stm8s

I would say that it is possible, but it would be a lot of work to make such software - unless you have access to source code that is run on this module.

You can always program fpga to act as a microprocessor and write sofware for it

Hmm, how did You program this board ? There is no ISP header. And also no UART header - this is must have, without it You will not be able to see the debug logs form the node and those are VERY helpful. There is also missing some decoupling capacitors around atmega. All VCC pins must have 100nF decoupling capacitor as close as possible - all digital ICs require that.

@alowhum while bulding spidev gateway you can specify second spi device so it will not overlap with the hat

@mfalkvidd it is clocked from the internal oscillator and works on 8MHz. The clock may be a problem, but would it cause overrun errors in the kernel driver ? I now connected the gateway through the pl2303 uart<->usb converter and I'm waiting to see of it helps.

i'm using rfm69 but this is not the problem with the radio, because I use ack'ing. The node will keep resending every 2 seconds when no ack recevied. When the problem happens, for example when i turn lights off and the controller does not get the status update which should be sent by the node, I see in the logs that the status update was received by the gateway but on the rpi side i see only first byte of that message.

Hi all,
I just realised that i have a problem with my serial gateway communication to controller. My gateway is an atmega328p based custom board and my controller is raspberry pi 3. Gateway is connected to uart pins (gpio14, gpio15) of the pi, and the baudrate is 38400. This works most of the times, but sometimes i can see in the logs that only part of the message is received by the pi. Below the output of the miniterm.py program:
11;1;1;0;3;0 -> OK
11;1;1;0;2;0 -> OK
1␀1;1;1;011;1;1;0;2;1 -> NOT OK
when that happens the overrun error count of the ttyS0 increases by one:
sudo cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550 mmio:0x00000000 irq:166 tx:19902 rx:358134 oe:1046 CTS

So it seems that it is rather a problem with interrupt handling (the overrun error happens when the buffer is full and new byte comes in), and not with the hardware connection.

Does anyone had the same problem ? Is my assumptions that the problem is related to interrupt handling correct ?

do You really need to take the box to do those things ? Why not just take the board out of the box and keep all the connections inside the box. There is always an option to have water proof connectors but I think that they make more trouble than it's worth.

@diogoc AFAIK no. I'm using mqtt with MyController (not Myscontroller) and it works great.

@michał-kozak Do you see incomming battery level message in mysgw logs ?

@maschler You can connect rfm69 module directly to raspberry pi and use it as mqtt gateway with openhab mqtt binding. Just follow the instructions You already found on mysensors website. Do You have any problems with running mqtt gateway on the rpi ?

@joaoabs said in Antenna for the RFM69:

the part that

I'm no rf antenna expert but to my understanding the length corresponds to unshielded part of the wire, so if the hole is surrounded by the ground plane then the length is measured from the pcb surface.

One very easy way to monitor the network health is to send I_HEARTBEAT_REQUEST from the gateway to arbitrary node - the node will respond with I_HEARTBEAT_RESPONSE. Well, this works only for non-sleeping nodes of course. If You are using mqtt gateway it is very easy to write a python script to send heartbeat request for example every 30 seconds and check if the response from the node came (I have written one and can share it with you).

Is it possible that your network problems are happening when you use a microwave at the same time?

@joaoabs i use 10u and ir works ok.

@dbagioni said in sha204 library questions:

return_codes is located in a sepa

I don't understand what You trying to do, but why do You want to "place it in the #include decleration" ?

thank, I will read that

proof: https://github.com/mysensors/MySensors/tree/development/examples/SecurityPersonalizer

@dbagioni the sha204_lib_return_codes.h file is in sketch folder so it should be found by the compiler.

Hi,

I was testing the current signing implementation and run into a problem that it makes comunication much more slow (to be precise 3 times slower). This is because to send one message, actually 3 messages have to be send (nonce request, nonce response and the message). I was testing it with soft signing because i can't get atsha204 chips in my country anywhere and ordering from abroad will be expensive, but i think that it would not make things much better because still 3 messages will be send (am I right ?). So for me this is not acceptable to have such a delay. For example I have a scene controller node and the dimmer node. When I click on the scene controller it sends message to the gateway and from gateway to the dimmer, so with signing there is 6 messages to send, and without signing 2. This makes the difference in timing like 1.75s vs 0.55s. Almost 2 seconds before my lights goes on.

So I read on the forum that the new mysensors (v3.0) will have new signing algorithm and that they will be not suited for atmega328 anymore. Can some one elaborate more on that ? Do these algorithms will not require 3 message to be send (I think this is critical for the setup I have) ? Why they are not suited for atemaga328p ?

try this site: http://www.s-manuals.com/smd

@mfalkvidd I also tried that outlaw trick and the results weren't satisfying I think that your microwave is more affecting the comunication than the wifi. This is another issue that I think that 2.4GHz is not suited for HA - can't turn on lights when using microwave is not acceptable

@titvs said in Introductions and Range Issues:

If everything doesnt go according to pIan, i guess im going to have to try to fit the RFM69 inside my already printed boxes and have an antena protruding out of the box… not very pretty…

You don't have to just use a flexible, insulated 1/4 wavelenght wire antenna and keep it inside the box. It does not have to be straight.

ok, thanks for reminder.

https://www.mysensors.org/hardware/nrf2rfm69
I tested it and it works. It is just a little bit larger than a typical nrf24 module.

@titvs I also would recommend to go for rfm69. I had exactly same problems as you, and tried a lot of differenr nrf24 modules and still couldnt get a descent result. As soon as i switched to rfm69 all my problems disappeared after all i spent more money on nrf24 modules than i would spend on rfm69 if i would start with them. Use nrf24 to rfm69 adapter board for easy transition.