Development

@waspie: done :-) Doe anyone have any idea about the retries? I'd like my nodes to keep trying to reconnect as long as they have power. Another question: I've read different things about #define MY_DISABLE_SIGNAL_REPORT Some recently said this saves memory, but I've found an older post that states it's already disabled by default.

@snyfir the radio uses so much power in listening mode that sleeping the mcu will not help much. To get low power, the radio must be turned off.

@alowhum yes it does. Documentation: https://www.mysensors.org/download/sensor_api_20#waiting

@alexsh1 Here's a bit of code I use to send an SMS once in a while. Providers will disable your simcard if you don't do anything that makes them money once in a while. Perhaps you can use it to reset. #ifdef SEND_SMS_EVERY_49_DAYS // This is an optional feature. // Every 49,7 days (using the millis() rollover) the system sends out an SMS. This helps keep the simcard active and registered on the GSM network. // Use at your own risk: if the system experiences a power loss, the timer starts at 0 again. If your experience frequent powerlosses, then the simcard might be-deregistered anyway, since the keep-alive SMS's won't get sent. // A slight delay is built in: the first sms is sent a week after the smart lock becomes active. This avoid sending a lot of SMS's if you are still playing with setting up the device, and powerlosses may be frequent. // This smart lock also offers another option. You can let the controller trigger the sending of the sms using the 'send test sms' button. Of course, your controller could also be down when you scheduled to trigger the button. static bool keepAliveSMSsent = false; // used to make sure an SMS is only sent as the milliseconds starts, and not during every loop in the millisecond. if(millis() < 5){ keepAliveSMSsent = false; // when the clock rolls over, set the variable back so that a new SMS can be sent. } if (millis() > 604800000 && millis() < 604800010 && keepAliveSMSsent == false){ // 604800000 = 1 week in milliseconds. Sending the first keep-alive SMS after a week avoids sending a lot of SMS-es while testing the system (which may involve a lot of reboots). keepAliveSMSsent = true; sendStatusSMS(); } #endif Alternatively, you could check out the smart alarm clock code. It will show you how to request the time from the controller, turn that into a human readable time, and then you can do your thing. uint32_t unixTime = 0; void receiveTime(unsigned long controllerTime) { Serial.print(F("Received time: ")); Serial.println(controllerTime); unixTime = controllerTime; breakUpTime(unixTime); } void breakUpTime(uint32_t timeInput) { // Break the given time_t into time components. // This is a more compact version of the C library localtime function // Note that year is offset from 1970! uint32_t time; time = (uint32_t)timeInput; uint32_t Second = time % 60; time /= 60; // now it is minutes minutes = time % 60; time /= 60; // now it is hours hours = time % 24; time /= 24; // now it is days //int Wday = ((time + 4) % 7) + 1; // Which day of the week is it. Sunday is day 1 Serial.print(F("Calculated time: ")); Serial.print(hours); Serial.print(F(":")); Serial.println(minutes); }

@mfalkvidd hey man thanks for the input. i was thinking to find radio related lines and see what kind of classes they use there and try to find the equivalents in lets say LowPowerLab’s library. is that a good way to go? i wish it was coded with mysensors it would have been much easier to switch in between :( i also found this library https://www.airspayce.com/mikem/arduino/RadioHead/annotated.html it also seems to support both modules. honestly i dont know which one is easier.

@msmacs Thanks a lot. This is it. I tried pins 10, 11, 12 (RX / TX / DE-RE) and it worked. Problem solved.

You don't seem to be using MySensors?

@michlb1982 Congratulations also from my side :smile: ! One additional remark: In case you want to use more relays and buttons, you may hav a closer look to the use of array functions. Good, but rather complex example: https://forum.mysensors.org/post/51488

@suhaila96 Hello I have not seen your question since I reviewed this topics, today. What do you mean about "setup your circuit"? How did you connected you watermark sensor and to what?

@cimba007 Can you post the complete code of the chirp including the headers? Did you only include these libraries: #include <SPI.h> #include "nRF24L01.h" #include "RF24.h" ?

@xypzo > One thing, the interrupt (motion) status is only sent when the other data (temp hum) is being send. So once a minute it jumps from "on" to "off" in stead of every time the Sensor goes HI/LO. Is there a way to fix that? Don't sleep the node. It won't be able to receive messages during it's sleep anyway so incomming messages will be lost as well.

@jimmy-loyens stuff in itallics i'm not absolutely shure about or are remaining problems. Anyone feel free to add or correct anything:grin: While writing this tutorial my node went offline :unamused: :confused: So it might be i have to add some more to the tutorial lateron :laughing: :smirk: Seems to be a problem with MYController because i can still see node trying to communicate over mqtt. I see its my sh***ty router acting up again, even my internet went down just now.:tired_face: :sob: It seems that somehow the firmware on my node got corrupted, when connecting it to a serial monitor it didn't output anything. When looked on MQTT.fx at the messages node and GW where continiously exchanging "stream messages. Then i flashed the node the oldfashioned way and now its all up again. Still trying to find out what happened exactly.

@jimmy-loyens I would test if sending all values every time really has a large impact on battery life. I don't think it has. An alternative is to keep a counter of how many times only lightlevel has been sent and transmit every n times. This solution doesn't adapt to varying interrupt times though. tekka is working on possibility to get the approximate amount of time left when woken up by interrupt. Your use case could be perfect for this new feature.

@sindrome73 Hi, shure you can bother me, happy to finaly help someone else (instead of asking help myself :smile: ). I dont really understand your quote since i dont speak spanish but i gues its a quote of my message. I just recently started playing with setting and requesting values so if someone (with more experiance) sees something wrong with what im writing here, feel free to correct me. Im using a mqtt gateway to communicate with my nodes. I have found i can use mqtt messages to set or clear a relay on a node withe the relay sketch (https://www.mysensors.org/build/relay) flashed to it by sending "mygateway1-in/nodeID/childID/Cmd/Ack/Type Payload" over MQTT. The "mygateway1-in" is the mqtt-topic for messages going to the node. (see this sketch for mqtt gateway https://www.mysensors.org/build/mqtt_gateway). The same should be possible using a serial gateway by sending "nodeID;childID;Cmd;Ack;Type;Payload" in the arduino serial monitor or any other terminal program (but i havent tried it with serial yet). Depending if payload is 1 or 0 the relay will turn on or off. You will notice in the relay sketch there is a function receive(). This is where the message to the node is interpreted and the state of the relay is set. The meaning of Cmd, Ack, Type and payload can be found here https://www.mysensors.org/download/serial_api_20. So when i want to turn the relay on on node 100 child 50 i actually send: "mygateway1-in/100/50/1/1/2 1", for turning it off i will send: "mygateway1-in/100/50/1/1/2 0". Notice in this case Cmd is 1 because we want to "SET" a value, and Type is 2 because it is a "binairy status". (see https://www.mysensors.org/download/serial_api_20). The same can be done for internal messages like requesting battery level or sketch name: Battery level => I_BATTERY_LEVEL => "mygateway1-in/100/50/3/1/1" => node returns battery level. Notice: Cmd=3 => internal message; Type=1 => I_BATTERY_LEVEL; Payload is empty => not setting anything Sketch name => I_SKETCH_NAME => "mygateway1-in/100/50/3/1/11" => node returns sketch name Notice: Cmd=3 => internal message; Type=11 => I_SKETCH_NAME; Payload is empty => not setting anything Same is true when requesting a sensor value, for example a temperature connected on child 12 of node 3: temperature => V_TEMP => "mygateway1-in/3/12/2/1/0" => node returns temperature Notice: Cmd=2 => Request; Type=0 => V_TEMP; Payload is empty => not setting anything Allso when setting a value other than for a relay, for example setting color of a RGB led on child 55 of node 47: rgb value => V_RGB => "mygateway1-in/47/55/1/1/40 0xffffff" => sets rgb ledcolour to white Notice: Cmd=1 => Set; Type=40 => V_RGB; Payload = 0xffffff => the value for r,g & b (in this case white) You can know wich Type value to use by looking in the sketch how the child is presented in present() function (S_HUM, S_TEMP, S_DOOR, ...) and looking up the appropreate V_value in the next table. (see https://www.mysensors.org/download/serial_api_20). Last remarque, the user (YOU) is responsible to write the code in the receive() function to handle incomming messages for the various types. You will notice in the relay sketch this is only done for V_STATUS because the sketch only has one type presented as S_BINARY. If your node has multiple children of various types you will have to expand your receive() function for any type you would like the node to receive messages from. If you make different functions for each type as you go allong and place these in the receive() function you should be able to re-use these functions in other sketches. I hope this helps, let me know how you get on Greets

@lorenzo said in nRF5 OTA updates: Hi, Any news on that? If needed I can help developping. No news from my side. Currently I have no time to work on this feature. You can fork my Repository https://github.com/d00616/ArduinoHwNRF5 to finish the work. It's possible to send a new firmware and the image is new replaced by the bootloader but with the first interrupt the MCU is crashing. For NF52 MCUs, I think this problem is fixable by moving the IV-Pointer to the image maybe there is an problem by different memory layouts of Arduino and Zephyr (used to compile mcuboot).

@miker none overrides the other. MY_TRANSPORT_MAX_TX_FAILURES sets the number of failed send() calls before the node starts searching for a new parent RFM95_RETRIES sets how many times RFM69 will try to send the message before send() returns false.

That's an interesting idea, thanks. Perhaps I could also make two children that contain the numeric count of how many devices are operational. Would this be something that could be relevant to build into MySensors?

@prelektr sounds interesting. Would be great if you can share the results later.