The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Spec revisions...


  • Subject: Spec revisions...
  • From: Patrick Lidstone
  • Date: Wed, 26 Mar 2003 09:38:00 +0000

A couple of thoughts to toss about re. the current version of the
spec.

1. Event based addressing
I've mooted this before, and although I know the (apparent)
complexity of current addressing schemes is contentious, I still find
myself wishing we could do "event addressing" as well.

At the moment, senders and receivers use schema which identify
functionality which is specific to the device. The idea of event
addressing is the introduction of -abstract- events which are not
tied to a specific device(s), but indicate a generic, system wide
change of status. Unlike source or target addressing, where messages
are one-to-many or many-to-one, events are many-to-many in the sense
that many devices can originate them and many devices can act on
them. Individual devices are free to act on the event or not as they
choose. Crucially, unlike the situation today, they do not need to be
explicitly configured to have a relationship with another device.
Examples might include an "audio.mute" event to silence devices
(perhaps with a message body which specifies the duration of
silence), or "occupancy.detection".
Whilst events could be used for group addressing too, that isn't
their primary purpose, and I suspect group membership probably needs
different semantics to allow for dynamic membership.

2. Heartbeats, devices and sub-addressing.
There is a case to be made for devices being able to support multiple
source or target addresses if they choose. Some pieces of hardware
may be able to support multiple logical functions that are totally
unrelated (e.g. Ian B's relay control, which is also capable of input
switch sensing, my rabbit board which can support two completely
different serial devices concurrently). The fact that these two
functions happen to be implemented on the same device is complete co-
incidence, and they really should be independently addressed. We
don't currently allow for that in the spec, and I think we should.
There is no issue for small devices here - we aren't doing away with
subaddressing, we're just saying that a larger device could support
multiple, independent source & target addresses. Such a device
would
also need to generate one heartbeat for each "core" address it
supported.

Thoughts?

Patrick






xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.