So I finally finished my motion sensor project and it works :)
It will be published on OpenHardware.io soon :)

I can now confirm that the apds 9930 module works without any issues. no steam problem so far and the module is located next to the stove. Here are some pictures :)

HAHA, You can always get a new wife with lower W.A.T (Wife Acceptance Treshold) :D

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

So today I created a simple python script to bridge serial gateway with mqtt bus on my RPI:
https://github.com/mczerski/MySensorsSerial2MQTT

This is because I already use spi for nrf24 module mounted on a custom pcb so there is no room for another spi device.

I found one on aliexpress: https://pl.aliexpress.com/item/GETIHU-360-Car-Magnetic-Phone-Holder-For-Phone-in-Car-Mount-Magnet-Universial-Mobile-Cell-Phone/32879720933.html?spm=a2g17.search0104.3.244.101611774LZhtS&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10151_10065_10344_10068_10342_10343_10340_10341_10696_10084_10083_10618_10304_10307_10820_10821_10301_10843_10059_100031_10103_10624_10623_10622_10621_10620,searchweb201603_1,ppcSwitch_2&algo_expid=17a12b56-7a20-49df-aab1-45b5519746f0-29&algo_pvid=17a12b56-7a20-49df-aab1-45b5519746f0&priceBeautifyAB=0

Hi all, I just wan't to share with You my idea about controlling bi-stable solenoids (let it be valves or latching relay, doesn't matter). And I wonder why nowbody considering this solution. I'm talking about this kind of circuit http://www.avrfreaks.net/sites/default/files/Latching relay driver.jpg. And those two transistors that have to be controlled with two pins may be replaced with a push-pull driver like L293 (or L203DD which has built-in clamping diodes) which can be cotrolled with just one pin (HIGH - open; LOW - closed). This L293 will make the hardware interface the same as with monostable relays.
So pros are:

1. simple circuit (relay, capacitor, L293 IC and additional capacitor for power supply filtering)
2. simple interface (use it like normal relay)
3. safe - bi-stable solenoids have maximum pulse with, with this circuit there is no possibility to cross that requirement (the pulse width is defined by the RC constant of the capacitor and solenoid)

Cons are:

1. the capacitor between relay and the ground has to be quite large about 1-2mF so its size is significant
2. the l293 ic maybe not very cheap

great news :) with the new nrf modules there is no more range problem :) for the gatewane i use nrf24l01+pa+lna and for the sensor node nrf24l01+. now from every place in my small flat the connection is perfect :)

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 ?

@Nca78 I'm also using 9930 and it is quite insensitive to transparent stuff, even partly transparent plastic cover. I am now finishing my kitchen and plan to put the sensor behind the milky plasic cover of the led aluminium profile, then drill the small hole for the ir diodes and cover the hole with fully transparent plastic. I made the prototype like this and it is working very well, but didn't test with the steam yet ...

no You can't, but You do not need an oscillator for atmega if You do not need precise timings, just use atmegas internal oscillator.

@pjr version is almost correct, it would be correct without references, so skip '&' symbol and it should work

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

so I went for similar ldo that I was able to get quickly TPS782, it is very similar to MCP1711. And I just made a test board with an atmega328p, nrf24l01 and voltage divider for the battery voltage measurement (1.1Mohm). In sleep mode it draws 7uA :) Think it is a pretty good result :)

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.

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

@magnusf It is important to know that the battery voltage is non linear in respect to how much juice left. Just search for "battery discharge curve" to see how much it depends on battery type, current and temperature. So calculating the percentage is actually meaningless unless You exactly know how much current your board sucks at what temperature and what type of battery You use.

don't know about HA, but I'm running mysensors mqtt gateway with openhab on rpi 3 (and Mosquitto as a broker), works without any problems.

depends on the sensors, some works with 3v some does not and they require boost converter. You will find everything in sensor datasheet.

@mfalkvidd said:

@rozpruwacz as mentioned on the list linked from the page I mentioned, OpenHab is a controller.

However, I think I read somewhere that it is not possible to hand out node IDs through mqtt, so you'll need to either use a different type of gateway or continue assigning node IDs manually. Either way is fine.

ok, understand, i can assign node id's staticaly, no problem.

As for the power, the capacitor on the nrf module has proven, over and over again, to be insufficient. That is why the radio connection instructions and the troubleshooting instructions mention adding an extra capacitor. It is not about the amount of power, it is about the
stability of the power.

so the additional 10uF should be sufficient, so what else could degrade the range ?
btw. a did this trick (https://www.youtube.com/watch?v=NpMnauHeR7Y) and it helped a lot, but it gets a little big :)

The heat sounds strange. I haven't seen that in any of my modules. Maybe the vendor sent defect modules?
i will try to measure the current.

and what about the issue with the communication not recovering from the blackout, e.g. if the mysGateway goes down the node would never recover unless i will recycle the power.