General Discussion

It's just ! I had forgotten this subtlety that the gateway is number 0. In MQTT what interests me is the topic of publication and subscription of the gateway. Thank you.

@mljbr4 You can change it on the fly by calling RF24_setChannel( c ); But, that's probably not going to work in your situation.... If you change it in before() it will be overwritten by the MySensors stack, if you do it in setup() you're already too late... What you could try is define a variable holding the channel, and make sure this gets set to the right value before MySensors starts, e.g.: uint8_t channel = 76; // default #define MY_RF24_CHANNEL (channel) #include <MySensors.h> void before() { channel = 90; // debug channel }

Wow, the comments are so old. Hope I didn't bother you guys. Now, I think it would be much better for us to get ourselves an automatic feeder. It would be much more convenient for us to feed our cats this way. Not to mention, you can control the diet and amount of food intake. If your cats have diabetes or similar conditions, getting an automatic feeder will help to improve their health a lot. You check all the important -Removed by moderator- before buying it too. Cheers.

The people that know me well say I'm one of the "need to see to believe" guys. Therefore I decided to get my SDR device out and install it on my PC. I then looked at the area around the 868MHz frequency. I then launched a fw update on one of my nodes, and waited for some of the zwave nodes to talk to the controller. This capture shows how the rfm69 module is talking at the 868MHz (center red band), while a zwave device send some short bursts of data at 868.4MHz. [image: 868MHz.jpg] The two red areas are quite well separated so it doesn't really look like they could interfere. I repeated the test several times and found that some zwave devices seem to be not perfectly tuned to 868.4MHz, and were transmitting at more like 868.35MHz. Even in this case, there are no signs of interference. [image: 868MHz1.jpg] I also took the opportunity to take a look at the 915MHz freq. In Spain this band is not free and happens to be reserved for the 4g data cell communication. In my area this band seems to be really clear, so I guess the cellular antennas are not using them. However, it's not an option if you want to follow the regulations. [image: 915Mhz.jpg]

@miclane great! Thanks for reporting back.

The sketch works using a direct, wired connection (RS485). T received - starting test... Sending Ping to Ying Node 2226167 TSF:MSG:SEND,201-201-1-200,s=1,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=OK:2226165 But it does not work with my RFM95's, but that is a completely different topic.

@wallyllama Nice answer - thanks very much. I'm going to go with a central power distribution point and send out 12v to any nodes that need powering. Each node will have a buck and drop whatever voltage they receive by that point, down to 5v. This way I avoid any voltage drop issues that could occur. It also gives me a single & scalable power source location and nodes close to their activity & still fulfilling their mesh roles and responsibilities! I like the @petewill setup, but will probably establish it using something like these: https://www.aliexpress.com/item/Free-shipping-1pcs-9-road-output-switching-power-supply-wiring-board-current-shunt-board-wit-fuse/693330771.html I was also thinking of going one step further with something like: https://www.aliexpress.com/item/9CH-DC-12V-15A-Switching-Power-Supply-With-Box-180W-Monitor-Camera-12V-Power-Transformer/32602759262.html but I'm not sure just how much to trust these? At least with just the first distribution board, I can power it with some old wall-worts initially (appreciate less power capacity). If anyone has anything good to say about the aliexpress switching power supplies, I may still consider. Cheers

@wallyllama said in A smart home vs an automated home: The trick is to get them to detect you without actively addressing them. If Alexa can detect breathing, or heat or CO2, etc, then it would solve the problem. If you enter a room and do not say anything, then Alexa has no way of identifying WHO you are. Even if the echo could detect breathing, heat, or CO2, you are back to knowing that someone is there, but not who.

@Steve-Hadley said in Idiot newbie question: f I build a node using another nodemcu Hi @Steve-Hadley as @gohan said In your case (when using esp8266 based boards) your gateways are the nodes at the same time because they connect to the controller by themselves. Just edit your code to accommodate your sensor and you got easily deployable node anywhere where in your wi-fi coverage zone without additional gateways.

I have seen all images with labels where to get some gpio pins on the pcb (I'd like to avoid soldering a cable directly on chip legs), but they are from all other models of sonoffs and not for the pow.

@tekka Tested the new library and both issues seem to be gone now, great job ! :clap: I have one more question though :) During testing I treid to put things difficult for my radios and move them until reception started to be bad. At some point the FOTA process gave up with a FW UPD FAIL message (line 41146 in attached log). So the node gave up and went to sleep. I was expecting it to try again after wake-up, but it didn't (see lines after 43589). 36734 !RFM69:SWR:NACK 36737 RFM69:PTX:NO ADJ 36771 RFM69:SWR:SEND,TO=0,RETRY=5 36966 RFM69:SWR:ACK,FROM=0,SEQ=119,RSSI=-55 36972 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12 36976 RFM69:PTX:LEVEL=12 dBm 36978 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 36988 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 36993 RFM69:SWR:SEND,TO=0,RETRY=0 37203 !RFM69:SWR:NACK 37206 RFM69:PTX:LEVEL=13 dBm 37216 RFM69:SWR:SEND,TO=0,RETRY=1 37423 !RFM69:SWR:NACK 37425 RFM69:PTX:NO ADJ 37459 RFM69:SWR:SEND,TO=0,RETRY=2 37666 !RFM69:SWR:NACK 37668 RFM69:PTX:NO ADJ 37679 RFM69:SWR:SEND,TO=0,RETRY=3 37885 !RFM69:SWR:NACK 37888 RFM69:PTX:NO ADJ 37922 RFM69:SWR:SEND,TO=0,RETRY=4 38129 !RFM69:SWR:NACK 38131 RFM69:PTX:NO ADJ 38174 RFM69:SWR:SEND,TO=0,RETRY=5 38313 RFM69:SWR:ACK,FROM=0,SEQ=120,RSSI=-56 38318 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=12 38322 RFM69:PTX:LEVEL=12 dBm 38326 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 38334 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 38338 RFM69:SWR:SEND,TO=0,RETRY=0 38547 !RFM69:SWR:NACK 38549 RFM69:PTX:LEVEL=13 dBm 38559 RFM69:SWR:SEND,TO=0,RETRY=1 38768 !RFM69:SWR:NACK 38770 RFM69:PTX:NO ADJ 38805 RFM69:SWR:SEND,TO=0,RETRY=2 39012 !RFM69:SWR:NACK 39014 RFM69:PTX:NO ADJ 39024 RFM69:SWR:SEND,TO=0,RETRY=3 39231 !RFM69:SWR:NACK 39233 RFM69:PTX:NO ADJ 39268 RFM69:SWR:SEND,TO=0,RETRY=4 39475 !RFM69:SWR:NACK 39477 RFM69:PTX:NO ADJ 39520 RFM69:SWR:SEND,TO=0,RETRY=5 39702 RFM69:SWR:ACK,FROM=0,SEQ=121,RSSI=-54 39706 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12 39712 RFM69:PTX:LEVEL=12 dBm 39714 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 39723 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520 39729 RFM69:SWR:SEND,TO=0,RETRY=0 39938 !RFM69:SWR:NACK 39940 RFM69:PTX:LEVEL=13 dBm 39983 RFM69:SWR:SEND,TO=0,RETRY=1 40192 !RFM69:SWR:NACK 40194 RFM69:PTX:NO ADJ 40228 RFM69:SWR:SEND,TO=0,RETRY=2 40435 !RFM69:SWR:NACK 40437 RFM69:PTX:NO ADJ 40480 RFM69:SWR:SEND,TO=0,RETRY=3 40687 !RFM69:SWR:NACK 40689 RFM69:PTX:NO ADJ 40724 RFM69:SWR:SEND,TO=0,RETRY=4 40931 !RFM69:SWR:NACK 40933 RFM69:PTX:NO ADJ 40943 RFM69:SWR:SEND,TO=0,RETRY=5 41125 RFM69:SWR:ACK,FROM=0,SEQ=122,RSSI=-54 41129 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12 41134 RFM69:PTX:LEVEL=12 dBm 41138 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005 41146 !OTA:FRQ:FW UPD FAIL 41299 RFM69:SWR:SEND,TO=0,RETRY=0 41506 !RFM69:SWR:NACK 41508 RFM69:PTX:LEVEL=13 dBm 41519 RFM69:SWR:SEND,TO=0,RETRY=1 41725 !RFM69:SWR:NACK 41728 RFM69:PTX:NO ADJ 41762 RFM69:SWR:SEND,TO=0,RETRY=2 41969 !RFM69:SWR:NACK 41971 RFM69:PTX:NO ADJ 42014 RFM69:SWR:SEND,TO=0,RETRY=3 42221 !RFM69:SWR:NACK 42223 RFM69:PTX:NO ADJ 42258 RFM69:SWR:SEND,TO=0,RETRY=4 42465 !RFM69:SWR:NACK 42467 RFM69:PTX:NO ADJ 42477 RFM69:SWR:SEND,TO=0,RETRY=5 42684 !RFM69:SWR:NACK 42686 RFM69:PTX:NO ADJ 42721 !TSF:MSG:SEND,22-22-0-0,s=1,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=NACK:0 42729 RFM69:SWR:SEND,TO=0,RETRY=0 42950 !RFM69:SWR:NACK 42952 RFM69:PTX:NO ADJ 42995 RFM69:SWR:SEND,TO=0,RETRY=1 43005 RFM69:SWR:ACK,FROM=0,SEQ=124,RSSI=-55 43010 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12 43014 RFM69:PTX:LEVEL=12 dBm 43018 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=1,st=OK:20 No detection 43026 MCO:SLP:MS=30000,SMS=1,I1=1,M1=1,I2=255,M2=255 43030 RFM69:SWR:SEND,TO=0,RETRY=0 43065 RFM69:SWR:ACK,FROM=0,SEQ=125,RSSI=-56 43069 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=11 43075 RFM69:PTX:LEVEL=11 dBm 43077 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=32,pt=5,l=4,sg=0,ft=0,st=OK:500 43585 TSF:TDI:TSL 43587 RFM69:RSL 43589 MCO:SLP:WUP=-1 43591 TSF:TRI:TSB 43593 RFM69:RSB 43595 RFM69:SWR:SEND,TO=0,RETRY=0 43606 RFM69:SWR:ACK,FROM=0,SEQ=126,RSSI=-56 43610 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=10 43616 RFM69:PTX:LEVEL=10 dBm 43618 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=33,pt=5,l=4,sg=0,ft=0,st=OK:30000 43778 RFM69:SWR:SEND,TO=0,RETRY=0 43788 RFM69:SWR:ACK,FROM=0,SEQ=127,RSSI=-59 43792 RFM69:ATC:ADJ TXL,cR=-59,tR=-80,TXL=9 43796 RFM69:PTX:LEVEL=9 dBm So when this occurs the only way I can think of to force another update would be update the sketch, refresh the repo in MysController and assign it to the node again. Therefore I wonder if this is intended behaviour and if so, if there is some other way to force an update after a failed one. Thanks.

Well, if you just want to look at the model, here it is: http://www.lacrossetechnology.com/c84428-wifi-connected-professional-weather-station I picked one up yesterday at Costco's bricks-and-mortar store. Not sure whether it will be easy to hack or not.

@siklosi how do you plan to use it? For a one time calibration or permanently mount it on the sensor? IMHO the voltage calibration of a battery powered sensor (if done at all) can easily be a one time calibration using a multimeter. I don't see the need for an accurate voltage reference...

@dbemowsk The serial API (=communication between controller and GW) doesn't distinguish between different transport technologies used in a specific GW. So it's not important if a GW is using nRF, RS485, RFM69, none or whatever else as a transceiver.

@pumpkinpi welcome to the forum! The flowcharts at https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help/ can probably be useful. You are correct that the radio wiring is ok since initialization works. You are incorrect that a few people has had to use a capacitor. Everyone has to. If not, problems will arise. Maybe not right away, sometimes people are just lucky and get the nodes partially working initially. But the nrf24 radios will fail sooner or later without a capacitor. I understand that the instructions on the radio wiring page weren't clear on this so I have adjusted them.

@smilvert Got it working: https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel#tabs-source I cited you in the credits at the beginning of the sketch.

@NeverDie It looks to be what can be expected after googlin' a bit; e.g. https://openawg.github.io/2016/04/19/first-test-chamber-constructed.html Opening the freezer's door will further disturb things (did it stay closed in both charts?) Were both measurements aquired using the exact same si7021 sensor?

see here : https://www.eevblog.com/forum/eda/oshpark-plated-slots/

My thoughts were to do as follows..... In the garage have a sensor>pro-mini>lora to send signal long distance. Then more locally have lora>pro-mini>serial data out to sedond pro-mini2. Then from second pro-mini2 serial data in>pro-mini2>nrf24l01+>gateway. So 2 x pro-mini with a serial connection back-to-back as a relay. But now you have described the application in much more detail I would be tempted to just add a lora gw as it's less bother.