@plantrekker: de afwezigheid van een master was overigens een voorwaarde voor de schoolopdracht waar ik die bus ooit voor ontwikkeld heb.
Je hebt absoluut gelijk dat het handig is om alle controllers simpel te houden, en de intelligentie in een centrale controller (of PC) te bouwen, zolang je met prototypes bezig bent, omdat je dan niet steeds alle controllers hoeft te flashen. Als je eenmaal dat stadium voorbij bent, maakt het wat dat betreft niets meer uit.
Ik ben ook helemaal met je eens dat een I2C bus voor de beperkte gevallen van een eenvoudige vorm, en niet meer dan 128 nodes en weinig dataverkeer technisch gezien een prima oplossing is.
De elegantie van de controllers die allemaal in hun eigen kleine wereldje leven, waarin ze alleen met hun directe buren kunnen communiceren, is maar voor een klein gedeelte technisch, en verder meer filosofisch en kunstzinnig. Voor dergelijke projecten die geen direct nut hebben, is de beste technische oplossing niet perse de beste oplossing.
Daar komt trouwens bij dat zo'n bus ook technisch heel interessant kan zijn, omdat het eindeloos schaalbaar is. Daarbij kun je gaan spelen met het netwerk, bijvoorbeeld door in het geval van die golven een tegel ergens midden in het veld uit te zetten; die tegel zal hetzelfde effect hebben als een grote steen in een vijver; de golf zal weerkaatst worden, en er omheen gaan. Daarmee wordt ook meteen duidelijk dat het netwerk niet stil valt er er 1 verbinding uitvalt, in tegenstelling tot een I2C bus.
Je kunt een netwerk ook delen terwijl het werkt, en dan zullen beide stukken gewoon blijven werken, zolang ze voeding krijgen. Als je die twee stukken weer aan elkaar koppelt (eventueel op een andere manier dan het voorheen zat), zullen ze direct weer samen gaan werken, maar dan ook automatisch in de nieuwe configuratie.
Overigens moet ik er wel bij zeggen, dat als de clocklijn die door alle nodes gedeeld wordt hoog of laag blijft hangen, de communicatie natuurlijk ook stil valt, maar het gaat even om het idee.
Je zou natuurlijk een bootloader kunnen maken die via de genoemde bus kan communiceren, en op die manier het hele netwerk in een keer van nieuwe code voorzien. Je zou bij een pakketje firmware zelf kunnen zeggen "twee nodes naar beneden, dan een naar rechts", om het alleen in een bepaalde node te laden. Elke node die het pakket doorgeeft, zou de stap die hij daarbij zelf zet, van het pakket af kunnen halen, totdat alle stappen op zijn, dan is het pakket bij de juiste node uitgekomen.
Of de TS ook vreemde vormen wil gaan gebruiken, weet ik niet. Ik ben nu alleen aan het nadenken over de mogelijkheden van zo'n systeem. Even verder denken dan de originele vraagstelling van de TS.
Voor grotere oppervlakken zou je natuurlijk een andere bus kunnen gebruiken, of het opdelen in kleinere secties en de masters van die secties weer met een overkoepelende master laten communiceren.
Voor beide mogelijkheden is wat te zeggen.
@TS: die sensor van Farnell is misschien wel geschikt, maar in de datasheet staat dat het onvoorspelbaar is of hij na een trilling in open of gesloten positie blijft staan. Dat zou je kunnen verhelpen door een condensator in serie te zetten met de sensor, die laat namelijk alleen veranderingen door. Op die manier maakt het dus niet uit in elke stand het ding blijft staan.
Het nut van dat relais zie ik niet echt in; relais zijn veel te traag voor zo'n toepassing, die kan het trillen van de schakelaar of een ander contact nooit snel genoeg volgen. Je kunt natuurlijk wel een bipolaire transistor gebruiken, of een FET, als je meer stroom nodig hebt dan het contact kan leveren.
