General Discussion

The error says "Invalid Home". Please check the home page setting a little higher up on the settings page.

@terence-faul any solution so far? I found this: create a file, e.g. mysensors_bootloader_130_8Mhz.json and save it to ~/.platformio/boards/ { "build": { "core": "arduino", "extra_flags": "-DARDUINO_ARCH_AVR -DARDUINO_AVR_PRO", "f_cpu": "8000000L", "mcu": "atmega328p", "variant": "standard" }, "frameworks": [ "arduino" ], "fuses": { "efuse": "0xFE", "hfuse": "0xD2", "lfuse": "0xE2", "lock": "0x0F", "unlock": "0x3F" }, "name": "MySensorsBootloader 1.3.0 (Atmega328P@8M,3.3V)", "upload": { "maximum_ram_size": 2048, "maximum_size": 30720, "protocol": "arduino", "require_upload_port": true, "speed": 57600 }, "url": "http://www.mysensors.org", "vendor": "MySensors" } the platformio.ini should look like this: [env:mysensors_bootloader_130_8Mhz] platform = atmelavr framework = arduino board = MYSBootloader_8MHz.hex src_build_flags = -I/Users/dirk/Arduino/libraries/MySensors lib_deps = # Using a library name but I do not know where to store the MYSBootloader_8MHz.hex

@bladeback sorry, but it is not possible at the moment, as mySensors only supports one radio at a time.

@rejoe2 Hi, Thanks for feedback, I'll try code from alowhum first.

@alowhum done

@skywatch Take a look at my pan tilt project. A stepper i.s.o. servo can easily be achieved. I would recommend to use the AccelStepper lib to have a smooth movement.

It doesn't seem to work properly. It seems data is.. garbled? The first node does show up in Domoticz. It got ID #2 (not 1). It has one child, which is of the correct type. But the other 5 don't show up. The second node I tried shows up in Domoticz.. but it's very weird. It gets ID 148, and things like the node name are not there. Similarly, the child also has weird data: ID: 45 Type: Unknown! Name: 4101763563 I'm going to try a shielded radio module. // Update: same issue. It seems, in the log below, that some of the messages don't come across completely? 0;255;3;0;9;1679510 TSF:MSG:FPAR REQ,ID=1 0;255;3;0;9;1679514 TSF:CKU:OK,FCTRL 0;255;3;0;9;1679517 TSF:MSG:GWL OK 0;255;3;0;9;1681281 !TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 sg=0,ft=0,st=OK:0 <- HERE 0;255;3;0;9;1696642 TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1 0;255;3;0;9;1696648 TSF:MS0;255;3;0;9;1698251 !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=NACK:1 0;255;3;0;9;1702721 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,sg=0: 0;255;3;0;9;1702727 TSF:MSG:BC 0;255;3;0;9;1702730 TSF:MSG:FPAR REQ,ID=2 0;255;3;0;9;1702734 TSF:PNG:SEND,TO=0 0;255;3;0;9;1702737 TSF:CKU:OK 0;255;3;0;9;1702740 TSF:MSG:GWL OK 0;255;3;0;9;1705198 !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 0;255;3;0;9;1716798 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,G:BC 0;255;3;0;9;1716807 TSF:MSG11 TSF:PNG:SEND,TO=0 0;255;3;0;91716817 TSF:MSG:GWL OK ,0-0-2-2,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0 <- HERE 0;255;3;0;9;1724956 <- HERE TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sG:PINGED,ID=2,HP=1 D,0-0-2-2,s=255,c=3,t=25,pt=1,l=0;255;3;0;9;1728997 TSF:MSG:READ,2-2-255,s=255,c=3,t=7,pt=0,l=0,G:BC 0;255;3;0;9;1729006 TSF:MSG10 TSF:PNG:SEND,TO=0 0;255;3;0;91729016 TSF:MSG:GWL OK

There are also some waterproof ultrasound distance sensors you could use

@alowhum Thank you for sharing this! - This looks like exactly the kind of thing I was trying to achieve. Hopefully I get some time at the weekend to test it out. Cheers! :)

@terence-faul this is not a fail prove design. Nodes are not typically moved even within one GW. Each GW must have each one channel and the same goes for nodes. Otherwise, in theory you may have a situation that the same node is reporting to one GW and then to the other GW. For controller this is going to be a chaos. A lot of data will be shared between two similar child IDs, i.e. for example two similar temperature child IDs for one node will have one measurement assigned through the first GW to the first temperature child ID and another measurement assigned to another child ID through another GW.

@geforcegamer great, thanks for reporting the result. @sundberg84 next time you update your doorbell, maybe you should add the same changes.

Hmmm. Looking up scintillometers, I see they are advertised as "large aperture", so you may need an array of photo[diodes,cells], which adds a lot of complexity, matching, summing etc,but maybe you could get away with a condenser lens.

@grubstake yes it is still current info and works both for the new driver and for the old driver, which is used by default (and what OP asked about) If you are using the new driver you can set the frequency in hertz if you want to.

Thanks. I was thinking about the level that you define in beginning of sketch. RF24_PA_LEVEL

@flopp yes.

@benhub that's an interesting thought. Wouldn't it be easier to just make the code in the main node flexible instead?

@apl2017 on the öast message, the node is not getting ack from the next node. The mose common cause is i sufficiently clean power supply. What size of capacitor are you using? How is the radio getting its power? Adding wait(200) before the send call can help the power to stabilize. Since all communication before works, wiring and everything else should be ok.

@tymal77 yes. See the w5100 code example at https://www.mysensors.org/build/ethernet_gateway#wiznet-w5100-ethernet-module for which #define to set.

@rjgmba hi and welcome to the forum! https://www.mysensors.org/build/connect_radio decribes how to connect the radio for any node or gateway - it is not limited to serial. A gateway has 1 transport and 1 controller interface. The transport can be rfm69, nrf24, rs485, etc The controller interface can be serial, ethernet(tcp), mqtt So what you want is probably a gateway with rfm69 transport and mqtt controller interface. Program the gateway based on the instructions on the first link you posted. Change the code from // Enables and select radio type (if attached) #define MY_RADIO_RF24 //#define MY_RADIO_RFM69 //#define MY_RADIO_RFM95 to // Enables and select radio type (if attached) //#define MY_RADIO_RF24 #define MY_RADIO_RFM69 //#define MY_RADIO_RFM95 connect the radio based on the instructions on the second link.

@flopp I'd love to hear more about the kit you want to sell. I'm working on something similar, in a way.