Hmm. I’ve been trying to keep the C++ class hierarchy “single inheritance” only to keep things simple to understand. So I think your good question has two possible answers:
The quick slightly ugly answer is to inherit from SinglePortPlugin (via ProtobufPlugin or whatver) and then override
/**
* @return true if you want to receive the specified portnum
*/
virtual bool wantPortnum(PortNum p) { return ... true if p is in the range we care about }
The prettier answer would be that I should have perhaps allowed multiple inheritance here. And ‘SinglePortFilter’ should have been a ‘mixin’ class that anyone could multiply inherit from if needed. How about let’s wait to see if this is a common usecase, and if it is then that can be changed as a (fairly easy) refactoring.
The next plugin will be a store and forward message queue … I have a good idea of how to make this work, both automatically and manually. Just gotta figure out an MVP since I think this will take a few weeks for the full feature set I’d like to put in.
What is the purpose of mp.decoded.position.latitude_i and mp.decoded.position.longitude_i? I’ve been monitoring them for a few hours and they seem to always be unset.
The values of n where ( NodeInfo *n = nodeDB.getNode(mp.from); ) only seem to be updated when the sending device gets a gps location lock (and maybe from a phone, I haven’t looked). Given that, n->user.long_name and n->user.short_name are both blank until the sender gets a location lock. In another round of tests, n->user.long_name and n->user.short_name are both unset for half an hour even after the location is updated in the receiver’s node database. Is this expected behavior? Is there a bug here?
Edit: Sometime between 20 and 60 minutes in (I my terminal ran out of buffer) n->user.long_name and n->user.short_name got populated. Regardless, that’s a long time for a new node to know who else is on the mesh.
re 1. purpose of decoded.position.
These fields are ‘legacy fields’ for the old position model (from before we moved position and text messages into ‘regular’ data packets. Used to they were ‘special’. They are not set now and will eventually go away. We need to keep them around a bit longer because I want to let the current android app still work with “1.0” loads so that users who get new preinstalled meshtastic devices still work without updating.
The field itself is marked as deprecated in the protobufs, but C++ has no concept of warning about deprecation.
/*
* Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data
*/
Position position = 1 [deprecated = true];
That very well could be a (serious?) bug. Alas, I’m super busy today wrapping up my android tasks, can you put a bug in on github and I’ll look into it soon.
I think I’ve hit some sort of artificial limit on the number of plugins.
I added the start of another plugin, a Store and Forward Plugin with almost no functionality and is a copy/paste shell of my previous work. When this is initialized from Plugins.cpp, the display stops being responsive to button presses. When I push the middle button, I see “Trigger powerFSM 1” in the debug log but the screen doesn’t page through. The information does update, just button presses don’t trigger screen transitions. Everything else seems to work just fine.
The StoreForwardPlugin.cpp is just a shell at this point and the screen just doesn’t work as I’d expect.
Does anything jump out at you?
If you compile and try my source right now, the middle button of the tbeam doesn’t trigger the screen transitions.
oh yes - accidentally I hit the same limit yesterday. It was a nasty (but easy) thread bug. You’ll find it funny - we were silently ignoring threads after the first 15:
