Hello,
I am currently working on modifying the emonth firmware for automatic scanning of attached ds18b20 sensors. this uses the method that the dallasTemperatureControl library "tester" sketch uses. So far I have been successful in getting the scanning to work. All sensors are detected and read out over serial properly, but I am not getting the proper info through the radio. I have a feeling that the rfm12b library can't take an array in it's typedef struct, but I dont know of any alternative, scalable, way to do this. Can anyone give me suggestions?
My code can be found on github here and a screenshot of the serial output can be found here (It is semi corrupted because of the power saving that the sketch uses. windows also doesn't like copying corrupted text so that was not an option. aka screenshot)
This sketch should take any amount of sensors up to where the memory overflows from holding too many values, but also has an adjustable software cap for safety. This was created because I really did not want to modify the original code to support (and input hardware addresses!) of the 7+ sensors connected to my geothermal system.
Also, is it appropriate to link to files? or should I upload them to the form instead if not relevant once resolved?
Re: Emonth automatic onewire scan firmware issues
I don't think you can do what you have there. The rf12_sendNow() call requires the message ("rfPayload") to be a contiguous string of bytes, and uses sizeof() to get the number to send - you can have up to 66. In your case, because you have not dimensioned onewireTemp[ ], it is not reserving storage for the array. I'm not sure where the values are being written, but wherever they are, it's illegal! This is probably the cause of your corrupted print statements.
I think you have to dimension the array to the maximum you intend to use, then you can change the call to rf12_sendNow and give it the computed length of the message, rather than sizeof(...).
[Personally, I prefer small files & small pictures to be posted in-line, larger pictures and long listings to be attached to the post. If you have a lot of very large files, then it shows consideration if you in-line or attach a small, low-resolution image and leave the large file on an external source, so that people who don't need to see it do not download the file each time they look at the thread. And yes, I know browser caching ought to handle that but it seems not to sometimes.]
Re: Emonth automatic onewire scan firmware issues
Ok, I defined the array size using "MaxOnewire" and put in some failsafe code (Will not gather onewire data if there are too many sensors detected) although this meant that the packet size will automatically be the length of the maximum number of sensors. while this can be defined by the user much easier than finding and defining all sensor addresses, I would like the length to be automatically adjusted by the program once it detects all the sensors attached to the bus. Would I just have to redefine the "onewiretemp" array once I've counted the sensors and compute the message length for transmission? or would that not work?
I am also not very enlightened on how to compute how big an array is in bytes in order to take up the rest of the 128 bytes the rfm12b library can take per transmission. (Yes, it is 128 bytes, the library was upgraded ) would anyone be able to explain how to do this to me? If I can get the automatic array resizing to work, I will need to find out how big to cap the array size / number of sensors at.
If defining the array size works I won't know until I get back home tomorrow and can try it.
Re: Emonth automatic onewire scan firmware issues
I fixed resizing the array and set it at 60 sensors. Each sensor takes up 2 bytes (one int) and there are three original values taking up 6 of 128 available bytes, leaving 122 to be used by sensor values. to be safe I capped the amount of sensors at 60. "But wait!" you may say. "Won't that send the whole 126 bytes of data every time?" why, yes it would. If the rfPacketSize wasn't adjusted to only include values that are actually written to. (Computed from the 6 bytes of the battery, DHThumidity, and DHTtemp variables, plus the number of Onewire sensors * 2)
Basically the code reliably scans the bus, adjusts the packet size, and starts sending data. It is ready for review and then a merger into the openenergymonitor emonth master.
Let me know what you think!