Usage of PJON's dynamic addressing

[pfichtner]

All the examples use hard coded device ids (masters and slaves). Can ModuleInterface also be used with PJON's dynamic addressing?

[fredilarsen]

The reason for using fixed PJON ids is to keep storage and RAM usage small, allowing it to run along with a decently sized user sketch even on a limited device like Arduino Nano.
Introducing dynamic addressing will add a little extra code to this repo as well as pulling in the extra code from PJONSlave. This will noticeably reduce the space available for user code on small devices.

Also, using dynamic addressing would introduce added complexity and a little increased startup time. Not a problem, but simple is often best.

That being said, functionality could be added to let the matching be based on module name or module prefix instead of PJON id, using PJON automatic addressing. It could be enabled with a #define so that the base size could be unchanged when it is not needed. I am open to investigate this, but do you think it is worthwhile, when each device has to be programmed with some unique identifier anyhow, to be able to separate them from each other?

[pfichtner]

I didn't deep dive into the code of ModuleInterface but do the slaves know the ids of the other slaves? I thought that each module already has a unique name and that the modules are referring each other using their names?

My idea was to create a system where modules could be sticked together dynamically. I played around with PJON directly using an ATTiny84 as a slave so I guess it could be tricky to get MI working on it. The system I'd like to create is very similar to MI so I think I could take use of most parts of it if dynamic addressing is possible. So it would be great if you could take a look if it could be achieved without big efforts and without increasing the code size when not using it using the #define.

[fredilarsen]

The modules do not know the PJON id of any other module, not even the master.
The master knows the PJON id of each module, as well as a "module prefix" that is attached by the master to the outputs and settings of a module.

To get an input value from another module, the input has to have the name of an output (with "module prefix") from another module, and the master will take care of routing outputs to inputs. That is as far as the knowledge of other modules go.

This means that the only thing that is needed for communicating with a device is that the master knows its PJON id, and that each device has a unique PJON id programmed or remembered. The "module prefix" (e.g. "gh" for GreenHouse) is assigned by the master, and two identical modules with different PJON id must be assigned different module prefixes by the master to separate their outputs and settings. A module will not necessarily know its own module prefix.

In my setups, I program each module with a unique PJON id but leave the rest unchanged when flashing multiple copies of a module. It is up to the master to assign the module prefix that makes their "tag names" unique for exchange between modules and between the master and the web site / database.

[fredilarsen]

Just to clarify: the master relates to the modules by their PJON id, not their name. The name given to the constructor in the modules could actually be eliminated as it is now. It was planned to be used for matching, but then the PJON id was available as a more efficient approach.

But if introducing support for dynamic addressing, the name could be used for matching instead of the PJON id.

[fredilarsen]

Classifying this as "feature request" and leaving it open, to be evaluated and possibly implemented.