fredilarsen
commented
5 years ago The reason why I created this project was because I started with a master that knew every input and output of every device I added to my setup, causing the master to grow beyond control, and requiring changes for every addition.
The idea behind this repo is that the master does not know anything about the modules except their PJON id, and a prefix that the master assigns to use for their outputs and settings. Whatever a module needs and supplies is known only by the module itself, and the master will exchange these contracts at startup or when it is changed in a module.
There is an example master where the list of devices is hardcoded in a textual form like "SensMon:sm:10 LightCon:lc:20" in the master code. Like you say, the master would have to be changed and reflashed when you add a module. This could make sense if you create a static setup, perhaps without a connection to a web server at all.
There is another example, examples\WebPage\WINDOWS_LINUX_LUDP\GenericModuleMasterHttp, where the master retrieves this module list from the web server at startup. It is stored in the settings table in a row with id m1Modules (for the master with the default prefix m1). In one of my setups this looks like "GreenH:gh:4 HenHouse:hh:6 ShuntCon:sc:5 ExLight1:e1:12 SnowMelt:s1:13 CarHeat1:c1:14 CarHeat2:c2:15 ExLight2:e2:16 SunBlind:sb:17 Switch1:w1:40 Switch2:w2:41", listing all the modules handled by this master. Multiple masters can co-exist, and some modules may exist on remote buses, so activation of new modules is manual.
With the generic master, the master will never be recompiled, but as of now it has to be restarted after adding or removing modules in the configuration in the settings table. I have thought of adding two pre-built GenericModuleMasterHttp executables for Windows and Linux to the github page, to save users the task of building the program themselves. You can of course run it on a dedicated device instead, Arduino/RPI/ESP or other.
It is in the to-do list to let the master detect changes while running, to avoid the restart after adding new modules.
If it makes life much easier for you, I can raise this feature to the top of the list. With this in place you would connect new modules to the bus, then activate them by adding them to the list in the settings table, without restarting the master. Of course this field can be put in a web page so it is very quick to add new modules. Should I add a settings page to the example web site, to control the module list, transfer intervals and more?
akadlec
If i underestand right, master module have to know structure of each node, or i s there something like autodiscover? My idea is to build growable network where at the begening is one master and two slaves and after some time add another slaves, but without reflashing master.