synchronous serial network.

Other Hardware Home Automation
1

This is, or at least will be a home automation project.

I don't want a master, because it will essentially be a single point of failure.
I wouldn't object to a master clock, because this could easily fail over to other clocks if needs be.

I haven't decided on a hardware implimentation yet but the system needs to be configurable in a star format which implies that some sort of hub is growing to be required so that multiple line terminations do not pull the whole thing down.

I have a germ of an idea, nothing more, but it needs to do at least the following.

Everything listens to everything else all the time, functionality will be mapped into a shared address space, effectively.

Nodes will carry coding for multiple devices but that isn't important to this question, all I want to discuss here is how to transmit information.

Obviously with no master two nodes could attempt to talk simultaneously.
My thought process, this far, is to ensure that all messages carry a unique ID which will denote priority.

When a node transmits it will also need to recieve an echo to establish that the byte it sent was the byte placed on the bus, doing this requires that all TX data is synchronised at a bit, or at least byte start level.

If this can be achieved, and assuming the data line is passively pulled up so one or more transmitters can pull it down, then a node sending 10000000 would be masked by a node sending 11000000 and would stop transmitting further.
Since the 11000000 would not have been corrupted by the colllision that sender would continue.
(And no I haven't fully worked it the mask part of the protocol yet but some sort of stack/token system will be required)

I appreciate that the protocol will be complex, I can handle that, but I can't work out if the USART hardware can be coaxed into starting a byte at some precise interval following some event or other.

I am aware that I could probably bit bang this using interupts but don't want to go there if there is a way to trigger the TX accurately.

If anyone has any thoughts I would be greatful of the input.

Just as an asside... If I do this on standard IO I had wondered about using a passive clock and extending the pulse to encode a bit. That way all bits would have a pulse but the width would vary between null, 0 and 1.
Since everything would be seeing the same clock all bits would be inherently synchronised.

Not that I have the slightest idea right now as to the code required or maximum practical speed I could achieve by generating or measuring pulse width.

Thoughts?

Thanks,
Al

2

What you describe is pretty much exactly how ethernet and wifi comms currently work.

You might want to check out modbus also- its an established industrial protocol for just this kind of application.

3

I may be wrong but I think the overhead, code and hardware wise, is too great on ethernet.
I would also need to build a protacol that worked with data in ethernet packets as well as working out exactly how to effectivly do everything, ok most things, as a broardcast.

Modbus is not a good fit at all at least not if it is implimented as it should be and if it isnt, then it isnt modbus.
Also modbus is not a hardware standard, typically it is used with 485 or ethernet and occasionally 232 but it is always a strict P2P system with a master and many slaves.

To be fair that architecture could work for me if I treated the hub as a as the master and used it to broker information between everything else rather than using it as a repository of the system and using slaves as remote IO.

The point is that I want to try and avoid the need to explicitly send information to a node but have nodes listen for instructions that affect devices that they control. Doing it that way means that managing a many to many relationship between say switches and physical lamps that light an area is much easier than having ton define every interaction in a single master script.

I know I am bucking the trend here but I think with good reason...
X10 is the best analouge... Data at every zero crossing, almost like a dumb clock, but even that has been enhanced by varoious manufacturers to get functionality not available in the origional standard.
As far as I am aware almost all comertial products use some form or propriitory protacol. Clipsal C-Bus for example is almost exactly what I want/need at least it would be if a second mortguage wasnt required to switxch on a light and the code modules worked at more than 1/4 memory capacity.

To be honest If there was a system out there I could buy or copy that is what I would want to do...
I was expecting someone to point out that some protacol or other already did what I wanted and just to use that, there must be hundreds after all, but so far nothing has been mentoned that I wasnt aware of.

The input is much appriciated, at this point nothing is off the table and all points of view are useful in the process of making a decision.