Porting MySensors to work with the RadioHead library
-
@ToSa Wonder what the runtime values are...
-
@ToSa said:
SerialGateway with RadioHead:
Sketch uses 22,242 bytes (72%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,455 bytes (71%) of dynamic memory, leaving 593 bytes for local variables. Maximum is 2,048 bytes.What radio/Arduino IDE did you compile for?
For Serial Gateway, nrf24, Arduino 1.5.7 I get:
Sketch uses 20.962 bytes (64%) of program storage space. Maximum is 32.256 bytes.
Global variables use 1.471 bytes (71%) of dynamic memory, leaving 577 bytes for local variables. Maximum is 2.048 bytes.Wonder what the runtime values are...
Currently MySensor::setRadio creates an instance of RHMesh at runtime, so RAM usage is even worse...
-
This post is deleted!
-
@Yveaux said:
What radio/Arduino IDE did you compile for?
nRF24 / 1.5.6-r2
DEBUG turned on - your values appear to be with DEBUG turned offI did a few changes starting to reduce the header so I can't rerun with DEBUG off and compare right now...
-
A small digression from the main topic here, but I just tested the mesh functionality of the library. I took a laptop with a serial gateway outside of the range of my sensor and observed that it stopped working. I then went back a few metres and powered up a battery powered sensor which basically just sent hello every second and processed messages. I was able to significantly extend my range, experiencing only a few seconds of interrupt in the ping flow.
Moving back and powering down the intermediate node, the direct route was reestablished within a new couple of seconds and everything was working correctly again
I think I will have much fun playing with this.
-
@kolaf said:
I was unable to significantly extend my range, experiencing only a few seconds of interrupt in the ping flow.
Shouldn't that be "I was able"?
I want to be happy with you, but not sure now
-
You are most certainly correct, I have edited my original post. I'm suffering a bit from tendinitis, so I'm using speech recognition when I write. Sometimes it recognises almost exactly what I say
-
@Yveaux said:
The MySensors library currently has a solid nrf24 implementation and routing works fine (though not fully mesh) so there's no direct need to switch driver and routing layer.
What are the differences between the MySensors protocol and RH in terms of mesh dynamics?
I'm guessing that RH is more dynamicly configured, but I'd like to understand more.
-
@kolaf ah, great to see your results then!
I read some mixed results on the Radiohead mailing list regarding mesh, so good to see it's working for you.
BTW I'm in the progress of writing wireshark directors for Radiohead which can be used with the nrf24 sniffer. It'll give us better insight on Radiohead's performance and functioning.
-
It makes sense to migrate the MySensors last,sender and destination bytes to RH from,source,dest.
I do not think it makes sense to move type (V_code) or command into the RH FLAGs. Typically when such space is reserved for the protocol in the header but not yet fully used, it's subject to change as the protocal evolves. If part of the goal is to take advantage of the maintenance and ongoing development of RH, we don't want to set up a conflict - because other users are not going to use those FLAGs our way anyway.
Basically, Radio Head should be concerned with delivering a payload (set of bytes) to a node. Everything specific to just the MySensors application should be in the payload (as seen by RH). That includes:
- child id ("sensor")
- command
- V_code ("type")
- version (if needed)
- ack - is this still needed??
If we want to remain compatible with other RH users (ie: their development), rather than re-allocating bytes or bits in the RH header to our own purposes, we would be putting our MySensors' header in the RH payload, but omitting from our header the redundant fields which are handled by RH:
- last,
- sender,
- destination
The RH payload would include the reduced MySensors header plus the MySensors payload.
-
@Zeph said:
I do not think it makes sense to move type (V_code) or command into the RH FLAGs. Typically when such space is reserved for the protocol in the header but not yet fully used, it's subject to change as the protocal evolves. If part of the goal is to take advantage of the maintenance and ongoing development of RH, we don't want to set up a conflict - because other users are not going to use those FLAGs our way anyway.
From the RH documentation / the source code:
- for Datagram FLAGS:
A bitmask of flags. The most significant 4 bits are reserved for use by RadioHead. The least significant 4 bits are reserved for applications. - for Router/Mesh FLAGS:
Optional flags for use by subclasses or application layer
Not setting up a conflict with the RH code will be the biggest issue: the two benefits of RH are the multi radio support and the more advanced Mesh topology - which would be worth a couple of additional bytes in flash and ram - but the other reason for the big overhead is that several advanced features of the nRF24 chip are not used because they are not available in all supported chips.
Two examples:
- the multi-pipe capability of nRF24 would allow to filter traffic to only current address and broadcast and avoid that any other traffic ever reaches the MCU (only slightly less code but wondering if that helps with battery powered nodes).
- the ReliableDiagram processing in code essentially duplicates capabilities that are build into the chipset as well (auto-acknowledge / autoresubmit)
I know you are interested in getting RF69 supported but the question is how much negative impact for all the other users (with current nRF24 setup) is acceptable. That's like using the RF69 and implementing an AES encryption in code rather than using the build-in capabilities of the chip...
- for Datagram FLAGS:
-
Didn't want to sound too negative yesterday...
- I'm still looking at the RH library but changes will be major and will not necessarily be in line with the RH purpose so Mike might not want to merge them into the main codebase: mainly defining what driver is used at compile time of the library (similar to MyConfig) which would then allow to e.g. "bypass" the majority of ReliableDatagram etc.
- what we should definitely do is splitting application layer and network layer: no longer inherit MySensor from RF24 but create an RF24 instance at runtime / leave application layer message handling in MySensors / move network layer message handling to a separate class (the "driver" for RF24). This will make it way easier to switch radios in the future.
-
@ToSa said:
Didn't want to sound too negative yesterday...
- I'm still looking at the RH library but changes will be major and will not necessarily be in line with the RH purpose so Mike might not want to merge them into the main codebase: mainly defining what driver is used at compile time of the library (similar to MyConfig) which would then allow to e.g. "bypass" the majority of ReliableDatagram etc.
Is it not sufficient that we define the radio at compile time in the sensors and the gateway as we have done now?
-
@kolaf said:
Is it not sufficient that we define the radio at compile time in the sensors and the gateway as we have done now?
I'm talking about changing how the library is compiled and essentially having a separate ReliableDiagram class that bypasses manual handling of ACKs etc. and instead leaves reliable delivery to the radio itself. Mesh and Router are derived from the ReliableDatagram class - therefore we would need to define which radio to use prior to library compilation - not just prior to sketch compilation.
-
@ToSa said:
the two benefits of RH are the multi radio support and the more advanced Mesh topology
Could someone summarize the differences between the current MySensors mesh and the RadioHead mesh, and why the latter is preferable for us?
-
RH is a true mesh where every node can communicate with any other directly (if in range). All nodes acts as repeaters.
MySensors forms nodes forms a star network where every node has a parent and potentially a few child sensors. The gateway node is the "center". Every node always tries to find the closest (least number of hops) route to gateway.
GW / \ A D / \ B CIf B want to communicate with C messages has to pass A in the MySensors case. In RH C and B will communicate directly if the can hear each other.
RH does not use the nifty features NRF24L01 offers which offloads mcu (pipes/addresses) nor auto ack (impossible in RH setup). So nodes in range has to process every message it can "hear". And this can potentially be a lot.
-
@hek
Thanks, that was very helpful, and a good explanation.That helps explain the overhead in the RH library mesh. It sounds cool for some purposes, but it also sounds like possible overkill for the wireless sensor network. Allowing B and C to communicate directly is not a primary use case. The MySensors is purpose-built for the sensor network with central gateway use case, and is pretty lean thereby. As I see it, even allowing B to send to C via A is not a primary use case, but sort of falls out "for free" given the routing approach that allows repeating nodes.
Aside - can B send a message to itself via A?
In my case, I'm mainly focusing on multi-sensor nodes, so RAM or Flash could be in short supply with a larger radio library. Worse still, I want to be able to incorporate MySensors functionality into nodes which also have non MySensors functions (eg: xmas light control also usng nRF24L01+), so space is even more at a premium.
So while the RH option is interesting, and a lighter weight RH derivative may pan out, I hope the MySensor WSN radio layer will continue to provide a "lean and mean" alternative into the future.
-
@hek said:
RH does not use the nifty features NRF24L01 offers which offloads mcu (pipes/addresses) nor auto ack (impossible in RH setup). So nodes in range has to process every message it can "hear". And this can potentially be a lot.
So MySensors can use both individual node addresses as well a broadcast, while RH uses only broadcast (at the radio level)? I understand why RH needs to do this, and I wonder if the receive FIFO ever overruns with unneeded packets.
I wonder if MySensors gets much savings from using the auto-ack of ESB. If you already have network ack code anyway, how much code & ram is saved by sometimes using ESB (one hop away) and sometimes not? (I do get that a star network with no repeater nodes could use only ESB autoack and save some code).
-
@Zeph said:
So MySensors can use both individual node addresses as well a broadcast, while RH uses only broadcast (at the radio level)?
Yes.
I think end-to-end ack is very important. The inter-node ack is only used as a trigger re-routing today (if communication fails 3 times to parent node .. the node tries to find another parent).
-
Could someone please explain to me how the direct messaging of the NRF24 works? In my mind every radio network is a broadcast network on the physical layer, and it is up to the receiving radio to determine whether the packet is relevant or not. How is this different from your radios? Is it perhaps that your radios have a hardware address so that the filtering is done on the hardware level, while Radiohead uses a software address, so each packet has to be explicitly processed? I have no idea, I'm just guessing here...
-
Yes,
NRF chip offer 6 reading "pipes". In practice it acts as a hw filter for addresses between 0-255.
I use this to have one broadcast address (255) which all repeating nodes and gateway listens to and each sensor also listen to its own address.
-
Looking at the documentation for the RF69 (page 41) it talks about sync word recognition. This is a programmable word that apparently can be used as the node's hardware address, similarly to the NRF24. Perhaps it is possible to expand the Radiohead drivers to utilise this functionality where it is available for filtering incoming packets?
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network. I know that this is somewhat outside of the normal use case, but how fun wouldn't it be to build this? :-).
Personally I'm also a bit interested in direct sensor to sensor configurations to allow for tightly coupled control systems without the need for a central controller in the loop (all the time). I know, we have resource limits so that I can probably not have everything, but one can dream...
-
Nevermind the sink word recognition, this appears to function as some kind of network ID has to be the same for both the sender and receiver. However, there is also an optional address byte which is considered by the radio before the packet enters the FIFO queue. Page 55 of http://www.hoperf.com/upload/rfchip/RF69-V1.2.pdf
-
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
-
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications.
Yep, both pros and cons.
A nice feature you can do with MySensors is to set a static parent (when calling gw.begin()). This could be useful for a presence sensor e.g. mounted on a car set statically to contact a repeater node mounted near the garage. The car sensor won't try to find or contact any other node than the garage one.
-
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network.
Just brainstorming, but what if we consider adding the concept of a roving node to the MySensors network, without the overhead of a full mesh? Your use case doesn't require that all nodes be meshed with each other, just that a class of leaf nodes be able to move around.
If I understand, a gateway or repeater node will forward a packet from anybody, if it recognizes the destination (as a node id in its routing table). Suppose you had coverage of your corral (or whatever) via gateway and various repeaters. In theory (perhaps naive theory) the roving node could report to the gateway by broadcasting a message picked up by whatever repeater is nearest; being addressed to node 0, the repeater knows what to do with it.
There would be no network ack and no way for the gateway to send to the roving node as described so far. That is, unless this special "rover packet" caused each relay to rewrite that entry of its routing table as it was passed to the gateway, to enable an updated path back to the roving node. If your horses run around among many nodes often, EEPROM wear could be a concern, unless there was a small "routing override table" in RAM to handle roving nodes.
One part I'm not clear about is how to avoid two or more nearby repeaters both forwarding this broadcast packet from the roving node. That might be tricky if it often causes OTA collisions. It could also complicate the back route logic, IF that was implemented. If we could avoid or gracefully recover from collisions, the gateway and controller may be able to deal with multiple copies of the same packet (not unlike the MQTT level 1 "deliver at least once").
And - it might be technically infeasible to enhance MySensors networking to support roving nodes. But in that case I'm sure I'll learn something from the manner in which it's shot down
-
@Yveaux said:
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
-
The rovering node will be able to send its message (after a few failed attempts) in the current solution.
If even faster parent-search is required you can change the#define SEARCH_FAILURESin MySensor.h.
-
@hek Just to be clear, I'm not dependent on the mesh functionality. I think I could be very happy with the current MySensors functionality with the added part of supporting my radio
-
@kolaf said:
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
That's good!
-
@kolaf said:
There is a separate optional broadcast address byte.
Aha, I see that on page 57 now.
I think that would handle it! (I see no need for 6 address-filtered pipes, two addresses will do).
Yes, it would be nice if the RH library could take advantage of address filtering for those radios which support it. I'm not so sure auto-ack is important tho.
-
So, anyone still developing on RadioHead integration, or did all of you just give up?
I spend some time on writing Wireshark dissectors for RadioHead and integration of MySensors, to be used with the sniffer (http://forum.mysensors.org/topic/242/wireless-nrf24l01-sniffer-for-mysensors)
Code is almost final (still have to test dessection of routing tables).Just as a preview, here's a screenshot to hopefully get you enthusiastic again!
-
-
I'm still a bit in doubt how sleeping nodes fit in when using RadioHead.
It has no notion of sleeping nodes and just expects all nodes to be available anytime.
When a route is e.g. discovered which uses a node that is about to go to sleep, routing will fail, but probably the route will then be rediscovered and finally settle using a node that is continuously powered.
How long this will take and the likelyhood of such scenarios (depends ofcourse on the amount of nodes and how often/when they are awake) is still unclear to me.
Hopefully I can analyze some real-world behavior using the sniffer.
-
@Yveaux said:
So, anyone still developing on RadioHead integration, or did all of you just give up?
no progress on my end - but that's rather related to the fact that this was my first week back in the office after vacation...
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
That way it would be rather easy to make use of other radios and other network topologies - could be RH or something else. I've taken a shot at that (a lot of this based on what Kolaf and Yveaux did adjusting MySensors to RH) and will provide a link once it compiles and is tested and I hope I can keep the overhead small enough to be acceptable for the gained flexibility.
-
It is great to see that something is still happening. I wonder if I can build a packet sniffer for the RF69 radios? I guess it shouldn't be that difficult since they receive everything that is sent...
The reason for my lack of progress late the has several reasons.
- I have a version of the library networks for my simplifications. This means that I can start building small sensors instead of spending all my time on the library
- My kids think I spent way too much time on this project already
- I'm waiting for some kind of consensus to emerge.
My hope has been to get this new radio library thing to a point where the community would adopt it so that I would not have to do any specific maintenance to keep my copy up to date with the official version. Based on this very long discussion thread there seems to be interest among you guys to achieve this, so I hope we will be able to get there at some point. However, we need to agree on how it is to be done, how much of the Radiohead library we want to use (or maybe even use a different library?). This obviously depends mostly on resource constraints considerations, and I'm not the best to judge this since I have not used MySensors extensively.
It is great to see effort being spent on trying to reduce the footprint, and as an experiment it makes sense to do this. Once we have seen how small it is possible to make it, then we can perhaps agree on what features we want (everything, or just the device interface, maybe with RHDatagram manager class (without acknowledgements)).
I'm holding back on developing any more this until we have reached some kind of consensus since I do not really have time to play around too much without being a relatively sure that the results will be useful.
- I have a version of the library networks for my simplifications. This means that I can start building small sensors instead of spending all my time on the library
-
@ToSa said:
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
Initial version - tested with a simple DallasTemperatureSensor setup successfully here
Note that this fork/branch does not include the "1.4 update 1" changes for nodeID / CRLF.Overhead is limited (~150b flash / ~20b ram):
Sketch uses 20,426 bytes (66%) of program storage space. Maximum is 30,720 bytes.
Global variables use 575 bytes (28%) of dynamic memory, leaving 1,473 bytes for local variables. Maximum is 2,048 bytes.
-
Care to share any details on which parts you took from where? Is it basically the Radiohead drivers with the MySensors network layer? Or did you make more effort on trying to split everything up to a larger extent
-
@kolaf it's only splitting the MySensor application layer form the underlying network layer. Still using the MySensor tree network topology and the RF24 driver. It's adding the framework to allow others to easily integrate other topologies (e.g. mesh) and other radio modules (e.g. RF69). The interface expects a reliable submission - no matter if that's achieved by software (like radiohead) or hardware (nRF24).
The MyDriver header file includes a short description of the routines and it should be fairly easy to attach it to radiohead. The main benefit is that the original MySensor tree setup still works as before if wished.
-
@ToSa said:
Initial version - tested with a simple DallasTemperatureSensor setup successfully here
Note that this fork/branch does not include the "1.4 update 1" changes for nodeID / CRLF.Looks good @ToSa!
-
@ToSa Could you give me the link to your repository?
-
@kolaf click the "here" in my post above - or use this:
https://github.com/ToSa27/Arduino/commit/328757d5bdb2681257326761fe1a0d90cdc3eba3
-
@ToSa Got it. My apologies for being slow, it was getting late ;).
Itlooks like this should be quite easy to work with. For the RF69 driver, maybe I could even use the unreliable datagram service from Radiohead And Configure the Driver to Use Hardware Acknowledgements (I Believe They Exist).
I will make an effort in this direction during the next few days, I hope. I'm curious to see how much space this requires compared to the NRF24 solution
-
@ToSa I was trying to fork your repository in order to build the driver for the RF69 based on Radiohead. It does not seem to work, maybe because I already have a fork of the main mysensors repository?
Maybe I can just check out your code, add the necessary files and be allowed to push it back to you?
-
@kolaf said:
maybe because I already have a fork of the main mysensors repository?
yes - Git doesn't allow two forks with the same base name (Arduino) for one user. We are about to move the changes into the mysensors/development branch. That way you can pick it up from there...
-
@ToSa Great, I will add my changes when you have done this.
-
It has been implemented, but I won't bother testing it until your changes have been merged with development, I don't want to mess up my existing development environment. My biggest uncertainty is whether this set up will allow the Radiohead library to be installed as a regular library in the "libraries" folder or if it has to be put directly into the MySensors folder.
-
Is there any progress of merging into the development branch? I'm currently holding off of building anything definitive for in-house deployment until we have settled on a relatively stable base for the code.
On a side note, I'm currently deploying Z wave actuators for all the lights in my house (we're refurbishing the entire electric system, anyway), and I must say that I am not very happy with the closed nature of the Z wave network management. I have gotten to the point where I believe that if I were to replace all the Z wave components with MySensors components I would get a much more stable system. Unfortunately I will get in trouble with the authorities if I try this
-
@hek It looks to me that all the activity that happen on getting the RFM69 integrated as part of the Mysensor ecosystem is dying. Can we not see if we can talk to Felix from Lowpower (https://lowpowerlab.com/) to see if he is not willing to get his Moteino integters as part of the MySensor ecosystem. Here is the tread on his forum where I asked him about this. https://lowpowerlab.com/forum/index.php/topic,542.0.html
-
The integration has not stopped. It is just a bit slow as we all have lots on our plate
Felix has actually sent me a couple of Moteinos that arrived a few days ago.
But the first step is to separate radio code from the rest of the library. @ToSa has begun this work and is nearly finished. Guess he is swamped with work as I haven't heard from him the last couple of weeks.
https://github.com/mysensors/Arduino/pull/36Then we can create a new driver for the RFM69.
-
I am waiting for the new radio separation code to be merged into the development branch. I have a working implementation (I think) of the RadioHead RFM69 library using his new code. I don't mind the wait, though, because I have lots of other things to do in the meantime and I can still build sensors using my own version of the library
-
Super @kolaf! Can't seem to get in contact with @ToSa. Maybe time to take it in (even if the config thing is unresolved) to get some progress.
-
The driver refactoring has now been merged into development. Ready for RFM69!
-
Working on it, fighting git about a rolled back rebase...
-
I managed to resolve my git problem, but I'm now back to a problem we have discussed before.
The problem is with how I should include the driver in order to use it without having to modify the header of every driver file. Can't seem to find what we landed on last time...
-
You mean every sketch file?
Guess you'll have to do like we did with rf24 and add it to the utility folder. Or maybe I misunderstand the question.
-
I mean that I have to place the RadioHead library inside the main my sensors folder for everything to work. If I were to place it in the "utility" folder, I would have to change every include inside the library to use" instead of brackets.
Anyway, I have gotten it to compile, and there is some radio communication going on. Trouble is that there seems to be some issues with the buffer sizes (I guess?).
Here was what the sensor is sending:
find parent
send: 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,st=bc:And this is what the Gateway is receiving (with an additional debug message from me):
0;0;3;0;9;read: 0-0-0 s=255,c=3,t=6,pt=1,l=1:0
0;0;3;0;9;version: 0
0;0;3;0;9;version mismatchObviously something is getting mangled along the way...
-
Good that something is transmitted.
But should you really use RadioHead? That seems a bit redundant.
Felix over at LowPowerLab directed me to: https://github.com/LowPowerLab/RFM69/
-
I got something working with a new library. Requesting node ID, and sending all initialisation stuff seems to work correctly. I was not able to place the libraries in the correct place this time either, but perhaps you can move them and re-factor the code?
I created a pulled request so that you can look at it.
This is happening in the gateway with the new code:
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 1-1-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=8,pt=1,l=1,st=ok:0
0;0;3;0;9;read: 0-1-1 s=255,c=3,t=8,pt=1,l=1:0
0;0;3;0;9;send: 0-0-0-1 s=255,c=3,t=8,pt=1,l=1,st=fail:0
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=6,pt=1,l=1:0
1;255;3;0;6;0
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=11,pt=0,l=13:Wave switch 3
1;255;3;0;11;Wave switch 3
0;0;3;0;9;read: 1-1-0 s=255,c=3,t=12,pt=0,l=3:1.1
1;255;3;0;12;1.1
0;0;3;0;9;read: 1-1-0 s=1,c=0,t=3,pt=0,l=3:1.4
1;1;0;0;3;1.4
0;0;3;0;9;read: 1-1-0 s=3,c=0,t=6,pt=0,l=3:1.4
1;3;0;0;6;1.4
0;0;3;0;9;read: 1-1-0 s=2,c=2,t=2,pt=0,l=3:1.4
1;2;2;0;2;1.4
0;0;3;0;9;read: 1-1-0 s=1,c=1,t=2,pt=2,l=2:0
1;1;1;0;2;0
0;0;3;0;9;read: 1-1-0 s=3,c=1,t=0,pt=7,l=5:23.2
1;3;1;0;0;23.2
0;0;3;0;9;read: 1-1-0 s=3,c=1,t=0,pt=7,l=5:23.3
1;3;1;0;0;23.3
-
Great @kolaf. I'll take a look.
-
Ok merged! Seems to compile fine with the library in utility after some minimal changes. Thanks @kolaf.
-
Excellent. I took a quick look at the changes you did to move the library, I'm a bit ashamed that I didn't manage to do that myself...
I'm very happy to have a solution in the development branch that allows the radios I bought to be brought along into the future of MySensors
-
Since I have four moteino , I wanted to test your code. Unfortunately, I have made a mistake , because the compiler return this error :
In file included from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:32:1: warning: "debug" redefined
In file included from C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:16,
from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriver.h:9:1: warning: this is the location of the previous definition
In file included from C:\Program Files (x86)\Arduino\libraries\MySensors/MyConfig.h:27,
from C:\Program Files (x86)\Arduino\libraries\MySensors/MySensor.h:17,
from My_Sensor.ino:2:
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: ISO C++ forbids initialization of member 'radio'
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: making 'radio' static
C:\Program Files (x86)\Arduino\libraries\MySensors/MyDriverRF69.h:40: error: invalid in-class initialization of static data member of non-integral type 'RFM69*'
-
IDE version?
-
This post is deleted!
-
This post is deleted!
-
Hi I now have my first MySensor RFM69 node up and running in PiDome
This is great as with the NFR24L01 I battle to get coverage in my House. I put the RFm69 node in the farthest point in my house any it just work. To get the NFR24L01+ to work at the same location I have to use an repeater node. The other thing I like about the RFM69 solution like Moteino (https://lowpowerlab.com) or Anarduino (http://www.anarduino.com/miniwireless) is the size you don't have to use any wires to connected the radio and it comes fitted to the arduino board. So if you look for a small sensor I think that this is the way to go for automation.
-
@Francois Cool! Is this compatible with RF24, as in, you can have RF24 based GW and other sensors, and "plug in" a RFM69 unit? With its better RF properties it sounds like an excellent candidate for use as repeater node as well.
Or is it required to set up a separate GW?
-
You cannot mix radios in one network.
-
@hek ok, så it is a different carrier frequency, or modulation, and not protocol-compatible on the "physical" layer? Pity.
-
@hek IDE Version : 1.0.5 r2
I tried with version 1.0.6 without success.
-
@kolaf
I've been busy with other stuff for some time but looking at the driver separation now once again. With nRF24 working (even bootloader adjusted to pick the right header files etc.) and two Moteinos at hand (Moteino RFM69W 868/915), I compiled and flashed a serial gateway and a simple temperature sensor node. Both appear to work fine looking at the debug messages except the fact that they don't listen to eachother. Both are sending but none is receiving anything (2m distance).
I did not touch or even closely look at the RFM69 driver code yet but will try to do so over the weekend. Do you have any hint where to check first?
-
I have the RFM69 setup working now with a couple of additional tweaks mainly for code optimization. Working fine for some time but stops after a few hours - I'll have a closer look the next couple of days.
Felix added three bytes to the payload (source address / destination address / control byte) to manage the acknowledge etc. in the lowpowerlab library. For our specific needs this is redundant as the current message format in development already includes this data. The three additional bytes are not that bad though and I'd propose to leave it like that for now and reconsider when we get to the revised message format :).
-
-
RFM69 is stable now for >48h.
The OTA bootloader version for RFM69 is in progress. I'm stuck right now where the node debug messages show that it's sending a packet but the gateway doesn't receive anything... I moved the full initialization code back in that I thought would be ok to skip but still the same behavior. Only difference to the full blown driver at this point is that I don't attach the interrupt but that should not be relevant for tx as I'm polling the interrupt register for status (ready to send / send complete etc.).
-
I had some time today to look at the bootloader code for RFM69 modules. Got the bootloader code to a point where it appears to be working fine - but the instability of the full MySensors RFM69 code is back - the serial gateway stops receiving packets after some time and it appears that the attempt to download a firmware by the bootloader just makes this problem more obvious due to the high volume of packets...
My prime suspect at the moment is the interrupt driven RFM69 library using a single packet buffer. As long is it's used sequentially everything should be fine but with e.g. submission or retrieval of ack messages it opens up the transceiver while the last packet was not fully processed yet potentially causing this... I'll go ahead and replace the routines in the library with the non-interrupt-driven version I coded for the bootloader just to see if this is the right place to dig deeper...
-
@bbbio24 Hi
I am running into the same " ISO C++ forbids initialization of member 'radio'" error. Did you manage to solve this issue? am using IDE version 1.0.6. What version should I use?Update: I managed to get past this error.
By the way I am woring with the latest develpment branch that I downloaded from here https://github.com/mysensors/Arduino/archive/development.zip.
To get past this problem I changed in MyDriverRF69.h the lne 40 to
RFM69 *radio;// = NULL;
This resolved the problem in the arduino IDE 1.0.6. Admittedly I am very new to this whole thing and am not sure what I potentially broe by changing the line bt at least I can explore further.
-
I used the Mysensors 1.4.1 library and managed to get a UNO with Ethernet shield and NRF24L01+PA+LNA working as an MQTT gateway.
I then changed the library to the latest development library (downloaded on 01.12.2014) and uploaded the MQTT gateway setch to the same hardware -> Also worked fine.
I then changed MyConfig.h to use the RF69 radio instead of NRF24 and just tried to compile. I got a lot of errors:
MQTT_Gateway_Compile_errors.txtI am using Arduino IDE 1.5.8
I am happy to help with testing, but I am afraid my programming skills are not good enough to assist with that.
-
@ToSa do you see the RFM69 only work on the serial gateway or will it also work on the MQTT gateway?
-
@TOSA I just popped back into the forum to report on my experiences with instabilities using the current version of the RFM69 code only to find that you have already had the same experience. This makes me quite happy since it means that at least someone else have had a chance to think a bit about it. On a side note, I really wish this forum had some functionality to subscribe to topics, it is not a forum I visit regularly enough to catch everything that's happening.
I do not have any good information regarding why the microcontrollers stop responding, but I see it quite regularly in both the Gateway and in the sensors. For instance, I have a power measuring sensor that counts the blinks on my power meter and toggles a LED each time the power meter blinks. I have to reset this about every two days (sometimes more often) when I see that the LED no longer blinks. All my current sensors are running the first version of the code based on your rewritten radio obstructions.
Please let me know if there's anything I can do to help out with debugging this. The instability is starting to get quite frustrating, and I was actually considering to go back to my earlier prototype implementation based on the radiohead library. I did not experience any such instabilities using this library, so at least we know it is not a hardware problem. As such it shouldn't be too difficult to figure out. Maybe it is possible to discuss this with the lowpowerlabs guy who developed the library?
Unfortunately my experience with debugging microcontrollers is limited, but I will help out where I can.
-
@ToSa I am running this version and I don't have any problems with it so far. I only have one node up and running with a humility sensor. I order 5 more Anarduino units and hope to get them in Jan so will do more testing then. The humility node is up and running now for more than 3 weeks with out any resets.
-
@ToSa How did you make the RF69 stable?
-
@CARSTEN I got the same compile errors. It turns out Arduino IDE 1.5.7 and above have a new compiler which requires PROGMEM data to be const.
See this discussion: http://forum.arduino.cc/index.php?topic=277173.0I was able to resolve the compile errors by adding const where flagged by the compiler:
In MyMQTT.h:
. . . .
const char V_0[] PROGMEM = "TEMP"; //V_TEMP
etc . ..Then:
const char * const vType[] PROGMEM = {
V_0, V_1, . . . .You also need to change the getType function in MQTTGateway.ino to account for the change in type of vType[]
char *getType(char *b, const char * const *index) { . . . .Compiled with no errors for RFM69 on Arduino 1.5.8 after these changes.
I have not had a chance to upload and test on my Motineo's.
-
Hi all,
Happy new year
I've just have the same idea, I'm new to arduino since chrismas
and I want to test mysensor with nrf905, It seem to be compatible with RH librairies.Could you just say me what i have to do ?
I'll have to include the kolaf librairies ?Just, If you have a link to the repository in order to work on it with you
Thanks for all
-
So, I'm working on it with the developpement branch of mysensor.
I've find some nrf905 librairies arround the web, but the RadioHead seem to be more powerfull and complete.
I'll give you news soon,First of all, i probably need help to diagnose because i've had only one raspberry, one arduino and two atmega328p chipset more
-
Did anyone ever solve the this compile error?
In file included from /home/andrew/sketchbook/libraries/MySensors/MyConfig.h:27,
from /home/andrew/sketchbook/libraries/MySensors/MySensor.h:17,
from SerialGateway.ino:27:
/home/andrew/sketchbook/libraries/MySensors/MyDriverRF69.h:40: error: ISO C++ forbids initialization of member ‘radio’
/home/andrew/sketchbook/libraries/MySensors/MyDriverRF69.h:40: error: making ‘radio’ static
/home/andrew/sketchbook/libraries/MySensors/MyDriverRF69.h:40: error: invalid in-class initialization of static data member of non-integral type ‘RFM69*’I have tried with IDEs 1.04, 1.05 and 1.06
-
@andrewm844
Hi,
I'm working on 905, so I don't have to check the 69, but I've the same compile error
I just replace
// RFM69 *radio = NULL;
RFM69 *radio;
in the MyDriverRF69.h file
-
Hi everyone,
i am new to MySensors. I already made sime Arduino pro mini running with a NRF24L01.
But i also bought some Anarduino with the RF69 installed. Can anybody tell me how i can tell the library to use the RF69 instead of the NRF24L01?
I used the Developement version of the MySensor library. I tried to find the point in MyConfig.h but i could only find the NRF24L01 Driver Defaults part.Maybe someone could help me.
Thanks in advance.
Benjamin
-
I'm interested in the progress of getting RadioHead working with MySensor....
what the current status??
where is the current code for this effort?
Thanks
-
In the development branch on github we have support for RF69. We have not incorporated the full RadioHead library.
-
Is there support for the MoteinoMega? with the rfm69? can you point me to a code base to start with??
I have used the MoteinoMega in other project, so I know a bit on how they work
Thanks
-
@ToSa do you have a sample project (serial Gateway or ?) that I could start from that uses the RF69W radio?? Want to develop with Moteino-Mega
thanks
-
You only need to initiate the MySensor class with the rfm69 class like this in the gateway (and sensors):
MyTransportRF69 radio;
-
I had done that, getting error...
Some questions:
I notice that the MyTransportNRF24 had definition for the pins in the function, RM69, has none...
I take it, its defaulted to the Moteino standards pinout?The file MyHwATMega328.cpp is for the 328, i assume that I would need to make one for the ATmega1284P chip? if there are any changes needed.
Thanks I will work on these error, if you have any insight on cause, please let me know...
(sure wish the IDE was better.....)
Arduino: 1.6.1 (Mac OS X), Board: "MoteinoMEGA"
SerialGateway.ino:56:26: error: no matching function for call to 'MySensor::MySensor(MyTransportRF69 (&)(), MySigningNone&)'
SerialGateway.ino:56:26: note: candidates are:
In file included from SerialGateway.ino:34:0:
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: MySensor::MySensor(MyTransport&, MyHw&, MySigning&)
MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: no known conversion for argument 1 from 'MyTransportRF69()' to 'MyTransport&'
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: MySensor::MySensor(const MySensor&)
class MySensor
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: candidate expects 1 argument, 2 provided
Error compiling.
-
Yeah, the work on the TransportRF69 need some polishing. It defaults to monteino pins right now. If you have the time add configuration to the driver, please help out.
I don't have any MonteinoMega so I really don't know how it differs regarding hw. Hopefully not too much.
-
I get the same error's if I select the standard Moteino and the RF24 radio???
so, I must have a version skew or IDE issue...
I'm using the source code form the development branch....
Arduino: 1.6.1 (Mac OS X), Board: "Moteino"
SerialGateway.ino:57:26: error: no matching function for call to 'MySensor::MySensor(MyTransportNRF24&, MySigningNone&)'
SerialGateway.ino:57:26: note: candidates are:
In file included from SerialGateway.ino:34:0:
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: MySensor::MySensor(MyTransport&, MyHw&, MySigning&)
MySensor(MyTransport &radio =*new MyTransportNRF24(), MyHw &hw=*new MyHwDriver()
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:78:2: note: no known conversion for argument 2 from 'MySigningNone' to 'MyHw&'
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: MySensor::MySensor(const MySensor&)
class MySensor
^
/Users/lafleur/Desktop/MySensor-Arduino-development/libraries/MySensors/MySensor.h:69:7: note: candidate expects 1 argument, 2 provided
Error compiling.This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.
-
@lafleur:
I got the same error, also 1.6.1 (Mac OSX) board Uno, and Nano. My solution was to remove the signing object in the initialization:// Construct MySensors library MySensor gw(radio);Then it compiles without issues. I have other issues though, but they might be related to the radios.
-
removing the Construct object, will cause other error, as the gw is not defined at this point...
SerialGateway.ino: In function 'void setup()':
SerialGateway.ino:67:3: error: 'gw' was not declared in this scope
SerialGateway.ino: In function 'void loop()':
SerialGateway.ino:85:3: error: 'gw' was not declared in this scopeI'm new to Arduino and this IDE, so it painful trying to work my way into this code...
-
Hi guys,
I lost some of my inspiration when I couldn't get the RF69 implementation to be stable for more than a few days and TOSA said he could before he disappeared without telling me how :-(. However, Easter is upon us and I thought I would give it another try.
I updated to the latest version of the development branch, and things seem to have changed a bit since I was here last time. Is there anything that needs to be updated on the RF69 side? At the very least it seems to be missing a definition for IS_RF69HW, as well as probably some useful defaults.
-
I also note that there now is an include for a specific radio in the serial Gateway example. This is different from the way it was earlier where the radio type was defined in MyConfig. Wasn't this a better solution?
Anyway, is it sufficient simply to change the included radio and then expect the serial Gateway code to work correctly on a moteino?
