Development

@Puneit-Thukral Could you post your full working sketch please? I'm revisiting some of my 51822 nodes that have sat collecting dust for a long time and thought i might try to get them working again.

@konbaasiang Thanks for the update. I've still the wavgat uno R3 boards somewhere, so I will try it :-)

@mfalkvidd said in Sample sketch for test node including hardware and software acknowledgement: char messagestring[100]; message.getString(messagestring); Serial.println(messagestring); @mfalkvidd Fantasic. Thank you. That is what I was looking for . It works now !!!

Tested this today: it works fine! In the meanwhile,I also found this: https://forum.mysensors.org/topic/2725/sensebender-micro/30 My platformio.ini file: [platformio] src_dir = WindowOpenSensor [env:sensebender-micro] platform = atmelavr board = pro8MHzatmega328 framework = arduino monitor_speed = 19200 lib_deps = 548 ; MySensors

@Yveaux Yes I had manually changed MyConfig.h to reflect the channel number I use. I thought I had read that was the way to do it. Okay thanks for putting me straight. Good to know it was just normal behaviour. I'll add it to each of my sketches in future. Thanks.

oh well... N2 was broken, it did not switch between RX and TX. We are discussing the issue over at Heltec community. Thank you.

Yes it is possible, using the SWDIO and SWDCLK pads. I programmed one to operate with MySensors using a black magic probe, but the J-Link also supports SWD programming. The tricky part is connecting to the pads. I just soldered on some wires -- not a very elegant solution, but it worked. You can get a reasonably priced J-Link EDU from Adafruit: https://www.adafruit.com/product/3571

@TimO Nice! Thank you for the suggestion. It seems to be performing much better using wait.

@tante-ju Sorry for the late reply, I have been away for a few days with work. While I am sure there will be more than one way to achieve your goal I have given a brief outline of the way i did it below. If all you want to do is request data from another node it should not need any more steps than @Sasquatch has listed above. Lets say we have node A with an id of 1 we also have node B with an id of 2 and it has a binary sensor with a child id of 3 Node A wants to know the the status of the binary sensor on node B So in your code on node A you will issue the request to query child id 3 on node 2 request( 3, V_STATUS, 2); The gateway will rout this directly to node B where you will need to have code to deal with the request in the receive(); function. In it's simplest form you could have something like this below. void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.getCommand() == C_REQ){ // message is request // put code here to be executed when the message is from a request // most likely you will call a function that will get the requested // data and return it to node A. If you are expecting requests for more than 1 // sensor you can use message.sensor to test which sensor the request is for } else { // message is from gateway,process the message as per normal // put code here to be executed when the message is from gateway } } } in the scenario above node B only expects requests from node A or commands from the gateway so it is easy to check what has arrived. If the message is a request we can execute code to get the required data and send it back. if it is a command (C_SET) from the gateway then it will fall through to the else part of the statement and be available as per normal. To send back the Data you will need to use a node to node message. this can be done on the fly, the format is shown below /* Node to Node message format. * * * * * * : Id of sending : message : Destination : Destination : Payload * * : sensor : Type : sensor Id : Node Id : */ send(MyMessage(sendingSensorId, V_STATUS).setSensor(sensorId).setDestination(nodeId).set(true)); //send message to desitination node So using our example you would have. (As we are not trying to actually switch any sensors on node A we can leave out the setSensor() part of the message) send(MyMessage(3, V_STATUS).setDestination(1).set(true)); Being a binary sensor the payload would be set to either true or false. Now we have sent the data all that is left to do is catch it in the recieve part of node A. One way to do this is simply to test for where the message has come from, if it is from the gateway (node 0) or in our case node 2. void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.sender == 0) { // check if message is from gateway (node 0) // put code here for normal gateway messages } else { // message is not from gateway so check to see if it is from node B if (message.sender == 2 ){ Put code here to deal with returning request } } } }

I also want to highlight one problem of the arduino IDE, and that is that it is very local to your machine. It makes hard to share your projects with others or even to migrate to a different machine of yours. This may not be a problem for casual editions, but as soon as you have build 5 or 10 things this starts to be a concern. People should be able to store their projects whenever they want and not be tied to specific paths/configs on a particular machine.

@BearWithBeard, compilation works fine after remove time lib. Thanks. Now I can play with mysensors. :smiley:

@cloolalang Other parameters not yet tested; sleep or wait between sketch information and presentation messages and/or in other functions MY_RS485_MAX_MESSAGE_LENGTH (40) #define MY_RS485_SOH_COUNT (3) MY_TRANSPORT_WAIT_READY_MS 0 MY_TRANSPORT_STATE_TIMEOUT_MS 2*1000ul In mysensors core: // Wait configuration reply. (void)wait(2000, C_INTERNAL, I_CONFIG);

Thanks for your explanation and links :)

It seems to be something nice. How is your project now? Did you understand what to do next?

it's probably a stepup for newcomers, and certainly a late stepup like others said. Well, I'm very glad with my favorites IDEs, so I'm not interested in it too, even for testing. One of my top priority when choosing an IDE (like any other tool) is productivity, no matter where the tool comes from. Privacy is important too of course, but not a problem with IDEs. So I'm fond of Jetbrains, VS and VS Code, and a few free-to-use mcu manufacturers IDE for best xp :smiling_imp:

A guide for converting sketches using MySensors 1.5 to MySensors 2 is available at https://forum.mysensors.org/topic/4276/converting-a-sketch-from-1-5-x-to-2-0-x

Hello, i don't see progress when connecting a 10uF decoupling capacitor. On my node i get 4452 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1 4673 RFM69:SAC:SEND ACK,TO=0,RSSI=-19 4677 RFM69:CSMA:RSSI=-110 4683 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1 4689 TSF:MSG:PONG RECV,HP=1 4691 TSM:UPL:OK 4694 TSM:READY:ID=1,PAR=0,DIS=1 4698 RFM69:SWR:SEND,TO=0,SEQ=5,RETRY=0 4704 RFM69:CSMA:RSSI=-107 4911 !RFM69:SWR:NACK 4913 RFM69:SWR:SEND,TO=0,SEQ=6,RETRY=1 4917 RFM69:CSMA:RSSI=-105 5124 !RFM69:SWR:NACK 5126 RFM69:SWR:SEND,TO=0,SEQ=6,RETRY=2 5130 RFM69:CSMA:RSSI=-107 5337 !RFM69:SWR:NACK 5339 RFM69:SWR:SEND,TO=0,SEQ=6,RETRY=3 5343 RFM69:CSMA:RSSI=-109 5550 !RFM69:SWR:NACK 5552 RFM69:SWR:SEND,TO=0,SEQ=6,RETRY=4 5556 RFM69:CSMA:RSSI=-108 5763 !RFM69:SWR:NACK 5765 !TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=NACK:0100 and on the gateaway 5919 TSM:READY:NWD REQ 5921 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0 5926 RFM69:CSMA:RSSI=-108 63949 TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0: 63954 TSF:MSG:BC 63956 TSF:MSG:FPAR REQ,ID=1 63958 TSF:PNG:SEND,TO=0 63960 TSF:CKU:OK 63962 TSF:MSG:GWL OK 64440 RFM69:SWR:SEND,TO=1,SEQ=1,RETRY=0 64445 RFM69:CSMA:RSSI=-95 64447 RFM69:CSMA:RSSI=-96 64463 RFM69:SWR:ACK,FROM=1,SEQ=2,RSSI=-34 64467 TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0 Loop 0 66524 RFM69:SAC:SEND ACK,TO=1,RSSI=-70 66528 RFM69:CSMA:RSSI=-105 66533 TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1 66538 TSF:MSG:PINGED,ID=1,HP=1 66546 RFM69:SWR:SEND,TO=1,SEQ=3,RETRY=0 66551 RFM69:CSMA:RSSI=-106 66754 !RFM69:SWR:NACK 66756 RFM69:SWR:SEND,TO=1,SEQ=4,RETRY=1 66760 RFM69:CSMA:RSSI=-97 66777 RFM69:SWR:ACK,FROM=1,SEQ=4,RSSI=-35 66781 TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1 Loop 0 68837 RFM69:SAC:SEND ACK,TO=1,RSSI=-69 68842 RFM69:CSMA:RSSI=-95 68844 RFM69:CSMA:RSSI=-96 68849 TSF:MSG:READ,1-1-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100 68855 RFM69:SWR:SEND,TO=1,SEQ=5,RETRY=0 68859 RFM69:CSMA:RSSI=-109 69062 !RFM69:SWR:NACK 69064 RFM69:SWR:SEND,TO=1,SEQ=6,RETRY=1 69069 RFM69:CSMA:RSSI=-101 69085 RFM69:SWR:ACK,FROM=1,SEQ=6,RSSI=-35 69089 TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100 Loop 0 71146 RFM69:SAC:SEND ACK,TO=1,RSSI=-70 71151 RFM69:CSMA:RSSI=-106 71156 TSF:MSG:READ,1-1-0,s=255,c=0,t=17,pt=0,l=5,sg=0:2.3.2 Loop 0 Loop 0 75212 RFM69:SAC:SEND ACK,TO=1,RSSI=-88 75217 RFM69:CSMA:RSSI=-108 75222 TSF:MSG:READ,1-1-0,s=255,c=3,t=11,pt=0,l=13,sg=0:RFM69 Sensor Loop 0 77279 RFM69:SAC:SEND ACK,TO=1,RSSI=-85 77283 RFM69:CSMA:RSSI=-107 Could you explain the difference between RFM69:SAC:SEND ACK,TO=0,RSSI=-19 RFM69:CSMA:RSSI=-110 When RSSI=-19 then RSSI=-110 ; which one is bad and is it on the node or on the gateaway ? Thank you again :-)