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
So today I created a simple python script to bridge serial gateway with mqtt bus on my RPI:
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.search018.104.22.168611774LZhtS&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:
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 ...
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 ?
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 ?
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.
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 ...
(No exponential backoff)?
its expotential, but no more than hardcoded value (don't remember what value)
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