I was thinking that future updates for “stationary relay nodes” should include the ability to respond to a relay test message. Additionally it should support the ability to easily collect coverage data and share it. I would like to hear other users comments on this function. Did I miss anything important to this feature? We can beg Gotenna for this after we figure out what would be most useful. I’ll update this post with any helpful edits. Reply below.
“Can you hear me?” or CYHM function
A universal “can you hear me?” CYHM GID would be assigned to this function.
Only stationary relay nodes would respond to the “can you hear me?” / CYHM requests.
By default Gotenna units will not notify users when they hear a response to a CYHM request they did not send.
By default any device that sends a CYHM request will listen for a CYHM response and notify the user of the response.
Users may turn on CYHM logging in the app settings so they log responses even if they did not initiate them.
When logging is turned on paired units will log their own location and date / time when they hear a yes response.
There will be a restriction set for both the number of requests sent and number of responses given in a set time period.
Under logging settings an option will be available “Notify me of new relay nodes”.
*This option will notify the user if it hears a CYHM response it did not send from stationary relay nodes they haven’t heard recently.
Under logging settings an option will be available “Share logs”.
The share logs setting will allow automatic log sharing or manual log sharing.
Manual log sharing will offer the option to upload to a central database or export to file.
Automatically shared logs will be uploaded to a central database.
The database url may be changed from the default url
An option will be available to “Share logs over cellular network”. It will be set to WiFi only by default.
Information from the logs that will be shared are Date, Time, and location.
Logs shared directly with Gotenna may be incorporated into www.imeshyou.com.
Thoughts?
EDIT 2017-11-07.1: Clarification: Stationary relays do not and can not send their GPS coordinates. They do not have a GPS and do not know their location. Addition: Stationary relay nodes may send battery level(Health check) and their randomly assigned GID in addition to a YES response.
The first thing that comes to mind for me reading your ideas is security. If the relays give out too much information too easily, they will be abused. If even not for real malintent, for fun. It’s just what people do. So security protocols/controls need to be followed and thought through.
I agree, I want to keep information sent very minimal. I think Stationary relay nodes transmit a randomly picked GID already when they communicate. Battery levels were suggested and I will add that to our informal “whitepaper”. Signal strength was suggested but I don’t think adding signal strength is prudent as information sent by Stationary relay nodes. That information if possible should be generated by the receiving node rather then a Stationary relay in my opinion.
Security, bandwidth, and power are reasons why I recommended the Stationary relay node should only send a “Yes I can hear you response”. If it wasn’t clear the devices that log the data are mesh units connected to a phone. They will log their own GPS coordinates and time when they hear a CYHM message not the location of the Stationary relay node. If a node hears a CYHM YES response message while it is not paired with a phone it will ignore that data because it isn’t useful without GPS.
EDIT: Item 7 was also meant as an anti abuse feature in addition to preserving bandwidth and power. I considered setting that time limit fairly high in regard to how often CYHM messages can be used but I haven’t figured out what that number should be yet.
EDIT2: I added the battery level to original post is response to @AMcl at the following thread/
I have ideas on how Relay mode units should respond, but I need to do some testing before posting. However, this snippet can be implemented now.
Eventually (hopefully) there will be too many user Mesh units in an area to unobtrusively ping stationary nodes via Shout. So, perhaps have a stationary node send a shout out when the battery is less than 20% might be better? This could either be activated as part of Relay Mode (and therefore disabled when simply turned on as an unpaired node). The message would be something like, “Hello. I am a stationary node in Relay mode. My battery is running low and is currently at 20% charge.” The message would repeat at 15%, 10%, and 5% charge with updated charge level.
@Rahul_Subramany, does a Relay node self-assign a random GID? Would a GID even be necessary if a Relay node was sending out programmed Shouts and has no need to receive messages other than for relaying?
For diagnostic reasons like finding a node that’s malfunctioning it needs some identifier. In your future nodes everywhere situation it could be problematic to not have an identifier.
The message would not be that verbose but rather it would be a simple code and then the battery level. The Gotenna app would then convert the error code to a message and present the battery warning to you.
We need to be very careful with this so it is not abused. I think the only “programmed shout” they will allow might be diagnostic in nature.
I hope to hear your fully fledged idea when you are ready. A battery warning of some type might be good assuming there is another unit out there to hear it.
It would be good to be able to connect to your relay and get stats on battery power, and number of messages relayed. That way people will have the knowledge that their relay station is useful and encourage more people to setup relays.
Battery status was already added as a recomendation in the original post.
I would like to hear the pros an cons of including number of relayed messages as well as other thoughts on things like:
How would we reset the counter?
Would only specific devices be able to access that data and reset it?
Would the Gotenna reset counter data every time it was put into relay mode?
If the node and or relay is part of a group could it then respond with a health message?
It could be assigned a area code, then store messages & forward them to area members. Respond to their health requests. Perhaps connect to other area nodes [gateway].
It also needs to power on in what ever mode its in when it loses power.
also could the UI rotate with the defaults of the device.
I’m not sure about storing and forwarding messages. That would probably work in an area of low traffic but in a high traffic area storage capacity might be an issue. Then we would need to think about bandwidth. For this to work the relay would need to know the unit it had a message for was in the area. Any ideas on how to do that efficiently?
A area code would be optin only to stationary nodes, even multiple DMR
[dedicated mesh relay]. More like a extended group adding DMRs call them
community codes.
if the msg has not been picked up, next area node that is heard, msg is copied to each area node that is heard until message gets to target node. When the msg is picked up, acknowledgements are passed back the same way.
I don’t know how much room the writers of the protocol have put in to the
headers. Packet radio has had various sorts of fortune with its method of
store and forward of messages. Area codes or Community codes would be just
for local traffic. In rural areas groups suffice.
We absolutely need a way to ping a dedicated relay device to determine it’s health & usefulness. For me, I’d be happy to be able to send a “health ping” message to a dedicated relay device that would return five values, 1)% Battery charge, 2)total up time since last reboot, 3)# of message in last 24 hours, 4)# of messages in last 7 days, 5)# of message in last 30 days. #1 & #2 would be an instantaneous readings, the other three would be rolling windows of time.
I understand the need for the random ID assignment, so you never have to worry about the relay unit receiving and storing messages meant for your phone (shameful copy). There are probably other good reasons if you think about the possibility of device ID collisions in large mesh networks.
But, thinking outside the box, what if you could set the “relay mode” (of a paired device) from the phone app? This would allow the app to capture the “random ID” assignment and use it in the future (no need to show it to the user). High-level steps would be:
pair device to phone
select (a new) menu option to switch device to “relay mode”
the app warns the user that relay mode will “unpair” the device.
if the user chooses to continue then the app instructs the device to generate the random ID, which is returned to the app.
device is unpaired, switches to relay mode, etc.
For example, what if a menu item was added to the app called “Relay Devices”. Selecting this menu option would allow you to see all the devices that were “placed” into relay mode using the app. Selecting any one of the items in the list would allow you to send a “health ping” that would return the above stats. I’m not sure if “health pings” are routable through the mesh. Initially, I would be happy to able to get near the device before sending the health ping.
In this way, the app could not only be used for communicating with others, but you could manage your dedicated relays all in one place. I’d like to setup 3-4 relays this year, but this is holding me back. This would be extremely helpful. I’m an iOS developer and would be glad to mock up the UX design if that helps.
Please read my post about adding a Beacon feature to a Stationary Mesh Relay Node.Without a periodic broadcast you would never know if a Node was within your range. Also a good way to test if it’s still alive and also a good way to check it’s range.