Development

@tbowmo Thank you, supercap idea works fine, my first experience with supercaps.

@apl2017 most MySensors nodes are battery-powered and sleep to conserve power, which means they aren't "on". With that said, most examples transmit on regular intervals. The interval is configurable, so you can set it to a short interval if you are not concerned with battery consumption.

Thanks I will try

If you compile Mysensors for Raspberry Pi as an ethernet gateway, you will be able to send commands to a socket on an IP of your Raspberry. You can use netcat command, or a python script, as described here: https://forum.mysensors.org/post/88439 This way, you won't need any controller software, if you are not planning anything big.

Sounds possible. Just try it, and enjoy learning.

@mfalkvidd , I see. That makes sense, thanks.

@mfalkvidd Use the W5100 module instead (if you need ethernet) Good idea, thanks! Same code, but only W5100 based: Sketch uses 17190 bytes (...) Global variables use 853 bytes (41%) Using W5500 ( Ethernet2.h ) gives even better: Sketch uses 14712 bytes (...) Global variables use 809 bytes (39%) If you don’t need ethernet, use usb or wifi since those options also use less ram. I need some kind of 25m wire so options are ethernet, RS-485 or PJON

@robvk said in MySensors 2.3 and RFM69 new driver. Problems and solutions: #define MY_PASSIVE_NODE Oh no I totally missed this line! This statement disables ACK and other transport-related stuff. Case closed.

Just to add for those using Arduino IDE, downloading the latest development version of MySensors fixes the same issue. Just go to https://github.com/mysensors/MySensors and hit "Clone/Download Zip", Download the zip then add to Arduino (Sketch -> Include Library -> Add .Zip Library then select the zip you downloaded). You may need to delete the old library folder from Documents\Arduino\libraries to ensure the new version is used. This will be fixed with MySensors 2.3.2.

@grumpazoid If you need inspiration, I wrote a number of sketches used in the MySensors Dollhouse setup, e.g. the Fireplace sketch. They can be found here: https://github.com/Yveaux/Dollhouse_sketches

@zen85 unfortunately not. See https://www.mysensors.org/apidocs-beta/group__RF24SettingGrpPub.html#ga6b3dbadceeb1dfca62b2e920d926bd4a for details (MY_RX_MESSAGE_BUFFER_FEATURE section)

Hi @pierrot10 and others, Sorry, I was called away unexpectedly... I've had no experience using nails other than testing the gyprock ones in the link I sent. I think your idea of 9 pairs spread across the wall is excellent as the key data you seek is the moisture source and how it progress across the wall. You can just connect the 9 sensors to one of those analog switch modules and the Feather and start logging data. You biggest problem will probably working out the distance between the 2 nails. Once it setup (in summer), you can make sure they all read the same value by a software 'calibration value' for each pair. I'd also suggest putting a newer BMP680 device in the room, perhaps 3" to 6 " away from the wall, just to have a temp, humidity and barometric pressure. I don't know exactly what it my tell you, but one thing I have learned is 'data is like money', there is no such thing as too much! (especially when you only get one shot at it a year). I think your chances of success look good as long as the distance between the two nails give you a sufficient data range. Good luck, and I look forward to reading how it turns out. Paul

@electrik Oh yes, that did the trick. Thank you so much

@wahid As an example, I have 4 sensebender micros, which has been deployed since june 2015, I have not changed batteries in them yet, and they still report temperature / humidity (that's more than 4 years battery life!). The batteries are cheap AA alkaline types (2 pieces).. I'm not doing anything special (hardware wise) to power off the radio, or any other peripherals on the board. Only using standard software powerdown where available.

@nca78 said in MySensors on ATTiny84 and RFM69CW: Hello, you should not use delay() with MySensors but wait(), which will poll the NRF24 regularly to receive incoming messages. You are surely right, that using delay isn't normally a good idea for a MySensors program. In my case I only want to implement a passive node to measure temperature and humidity. So my program don't wait for any incoming messages and delay wouldn't be a problem for this reason. But for the final version delay wouldn't be a good solution for another reason: battery life. But I have now a working sleep function for the ATTiny84 which needs only approximately 6µA during sleep. In the meantime I found the reasons for my problems. My program just uses to much RAM (only 512 Byte on ATTiny84 available), so the stack destroys other variables and the program behaves strange. But I now found a solution for a working passive MySensors Node for temperature and humidity on ATTiny84 with RFM69 radio module and the BME280 as temperature/humidity sensor. I will show my solution here anytime soon, maybe it is of interest for others who try something similar.

@malaki86 if you don't want to use a MySensors device for mqtt, I don't think you'll find a complete tutorial. But people have connected MySensors devices to nodered, and nodered can speak mqtt I think. A possible strategy could be to create a rs485 raspberry pi gateway https://www.mysensors.org/build/raspberry Add MySensors nodes to the rs485 network Connect the gateway to nodered Connect nodered to mqtt Alternatively, you can make the raspberry pi gateway use mqtt directly.

This explains how to do it: https://forum.arduino.cc/index.php?topic=610354.0 Fortunately, Optiboot 8 recently added a new function do_spm() which, from what I gather, you call from your code. It then takes the new compiled sketch binary that your OTA code is assumed to have placed at the end of flash, writes it to the beginning of flash, and then jumps execution to the start of the freshly written sketch. In a nutshell, it appears that's all there is to it. Prior to this, you had to write your own bootloader. It appears that now you can get by without having to. :+1: Instead, the heavy lifting is moved into your application code, where development is more familiar. That may not be as robust as having an unchanging, tried-and-true FOTA bootloader that's protected, but it does seem like an faster path to get a FOTA for a particular radio up and running across a range of MCU's without having to make a custom bootloader for each one. What a relief! I was on the verge of switching over to PICs because of this exact issue. Hopefully now I won't have to.