https://hackaday.io/project/2197-the-moteino-framework/log/8306-new-motionmote-and-oled-moteino-receiver (https://hackaday.io/project/2197-the-moteino-framework/log/8306-new-motionmote-and-oled-moteino-receiver)
QuoteI've been asked ... if I could build a standalone receiver for the Moteino network of things. Some people wanted .....an LCD to see the entire message and battery level, or other things like that.
Felix, I know it's been a long time since you introduced Motes, and Mote IOT scheme, and you may have moved on, but I'm still enamored with these little things, so thank you.
The question is: have you ever published your code for the improved version mentioned in the above link? The version that can get things like the Mailbox notification and see other incoming mote's data stream? I'm struggling with how to accommodate the different structures of data streams that come from varying (re)Motes and displaying them on the OLED. The pictures seem to imply that you did finish that version and got it working, and I have been unable to track down where the examples might be. I'd just like to see how you approached it if that's possible. Side note: I did switch to Adafruit's ssd1306 library as I was struggling with u8glib.
Appreciate all the effort,
Mark
After putting some more hours into it, maybe a refined version of the above question would be this: The Gateway example sketch uses a data handling scheme that assigns all the data to pass into mostly "char Xxx[10] and count them so that the Rx can make sure they all came in. On the Struct_send you use "typedef struct" to put them into a 2D array. In the example shown in the link above, it looks like you might be using the second option, and picking and choosing which elements you want to display at different times. If that's the case, are you sending the whole collection of available data, and then selective displaying different elements alternately?
My bottle neck is that different motes are going to have different data (possibly many different types of Units) and I'm not sure if I just sent it all how do I identify which units I'm displaying on a limited display?
Do I need to include all the possible data elements on every mote and just null the data that isn't used on specific motes to keep it all in order?
I'll keep monkey-poking until this becomes clear to me, but a peek at the code in that example would be useful.
Thanks
bo
Thanks for the message, question, and using my products (still!)
I have to find some time to dig into this and digest what I wrote in that post years ago.
Keep posting here to keep the thread hot and I will get to it.
Thanks for the patience!
To keep refining the question, I'll expand it further.
The sketch I'm trying to build is an attempt at a small monitor with a 128x64 I2C OLED for the purpose of watching a one of many Motes that monitor different things. Examples are a Mote that monitors voltage, one that monitors current, a WeatherMote, and a Mote hooked to thermocouples.
Obviously, I'm not going to get all those options on such a tiny display, so the Monitor(Mote) will have to distinguish between them, and adjust the display accordingly.
From what I can see, the "typedef struct" format used in the Struct_send example allows for identification of the different parts of the data stream, and I should be able to separate them and "case" to which ever display scheme I need for that particular data (and Mote).
Felix's example sited earlier seems like it might be doing that since there are two distinct display schemes. The other possibility is that they are just two separate unrelated examples and the data is not being identified and separated.
The PiGateway.ino sketch uses typedef, but it only seems to be to getting the length of the buffer needed. I have yet to figure out how that identifies the type of data and points the receiver to how to decode it.
I see 9 or 10 different types of data to send in my approach. Having a data stream with that many choices in all senders (even if unused in a particular Mote and sending null data as a placeholder) would exceed the usable data length.
Maybe that illuminates my situation, or maybe it muddles it with ignorant rambling. Not sure, but it brings me back to question of how do I handle differing data coming into one place? The Hackaday example seems to hint that you're doing something along those lines.
I guess a brute force solution would be to just make dedicated sender/receiver-displays pairs for each type of data that I want to monitor and move on to what I was trying to solve in the first place.
I appreciate anyone's suggestions on where to learn more about this, or at the very least, thank you for taking the time to humor a hobby programmer and read through it.
bo
I think I have found someone addressing a similar question.
https://johan.kanflo.com/serializing-data-from-iot-nodes/ (https://johan.kanflo.com/serializing-data-from-iot-nodes/)
For the time being, I'm going to explore his approach and see where it leads.
Cheers
bo
Rereading my last reply, I didn't mean it to sound harsh, and I think it did. I was just looking to learn different ways to to differentiate the data. After spending some time there, and seeing that the heavy lifting was done in the .js, I'm back here playing with my IoT gateway. It's still a fun system, and I think I can adapt my outcome with some more learning.
Thanks all that have contributed.
bo