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.search022.214.171.124611774LZhtS&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 ...
@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:
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.
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.
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:
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 ...