Reply To: Mayfly sketch compiles, seems to upload, but doesn’t

Well you are now into working deployment practice’s, beyond programming,

So how about simplifying  (I think you’re process is getting complicated . IHMO all the guideline haven’t identified what happens when you actually have a successful program to deploy .)

Seems the question is for  a successful working Mayfly logger program ….. and how to scale it   to the field.

…. you have a very good point

~~ grin ~~

Seems to me a really SIMPLE  way of solving it is to put the UUIDs in an include file – and then manage the include file separately so they don’t go to github.  Say “ms_cfg_uuids.h”  This works if its you (and any similar programmers/colleagues) are building and deploying to the field and you can agree on labeling and where to keep the ms_cfg_uuids.h

IMHO – this is a beta development scheme. For each Mayfly it still has to be be compiled with each separate ms_cfg_uuuds.h and then downloaded to each Mayfly, and tracked on a Mayfly basis.  IHMO2 this shows a weakness in EnviroDIY working practises , how to test a program to prove its successful.

If you want to deploy a number (10->??) or so loggers all the same,  … what then … Deploying a number of Mayfly loggers becomes a bit more of a production line.

What I do, in my fork, (and its a big step of functionality)  is put the UUIDs in a file ms_cfg.txt and then put it on the uSD. This is ideal for situations where colleagues are not programmers, but can configure a system through a built  .hex and then uniquely configure the system with ms_cfg.txt

The program can be tested, and with the captured .HEX file easily deployed in multiple numbers.

Its also easy to upgrade, as its the uSD that is the key to connecting it to MMW – not the program.

I wrote about it here https://www.envirodiy.org/geographical-scaling-modularsensors/

I also write about other features that I think are missing from the mainline https://github.com/neilh10/ModularSensors

hope that is helpful 🙂