RE: Re: Spec revisions...

[Ian B]

>Yes and no. It was the original intention behind sub addressing, but
>it only really works for related functionality. Perhaps the relay
>board is a special case, but the switches and the relays have no
>direct logical or functional relationship - and it doesn't make any
>sense for them to share the same core address.

Hi there.

I have not been following this too closely as I have been in my shed
playing
so apologies if this is a little off tack. I have however just finished (I
hope) the switches on my relay board.

1) These do not have a heartbeat. This is covered by the generic one for
the
relay board. No special mention either way.
2) The 'Inputs' schema currently only has a couple of methods.
2a) Status. This is sent in reply to an Inputs.status request. It simply
sends the high or low state of the switches and their numbers. The status
also says which edge the events are sent on (2c).
2b) Event. This is sent when a switch changes state according to 2c. The
body states which switch has changed and its new current state. The old
state is not sent.
2c) Behaviour. This is sent to the relay board unit and has a body saying
which edge the switch should send an event message on. The choices are
Rising, falling or both.

When addressing the unit the Instance is used with no SubInstances. The
schema identifies the fact that it is the inputs functionality that is
being
interrogated/changed.

Currently I do not support naming of switches and other fun stuff. There is
a slight code space problem there + time. You cannot address the switches
directly so no sub addressing is supported.

All this means the relay board now supports three schemas and numerous
methods. Way more complicated than I ever first thought it could be.

Thoughts?

Thanks

Ian


>-----Original Message-----
>From: Patrick Lidstone [mailto:<a
href="/group/xAP_developer/post?postID=ei7DeheMI35FveX28G64-Av0jyPpQylTlG5DJBNvq1-ti58WgLLWRzGR3mdL7o-uKmj4JFQF_cv4zrlplt4">patrick@l...</a>]
>Sent: 30 March 2003 12:17
>To: <a
href="/group/xAP_developer/post?postID=CmA9Xqj00EZXySmLCOoopuHF_5D3O9f0IRQj3kNj7_yqT6Q-6UUTixAIG8Hd3dA6NrKMXtqhG81r2H9VpVMrZxu1q2expw">xAP_developer@xxxxxxx</a>
>Subject: [xAP_developer] Re: Spec revisions...
>
>
>--- In <a
href="/group/xAP_developer/post?postID=CmA9Xqj00EZXySmLCOoopuHF_5D3O9f0IRQj3kNj7_yqT6Q-6UUTixAIG8Hd3dA6NrKMXtqhG81r2H9VpVMrZxu1q2expw">xAP_developer@xxxxxxx</a>,
Stuart Booth <lists@s...> wrote:
>> On Wed, 26 Mar 2003 09:38:24 -0000, "Patrick Lidstone"
>> <patrick@l...> wrote:
>>
>> >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.
>>
>> Do you happen to have an example of what you mean by this?
>>
>> Taking your audio.mute example, I'm thinking that an untargetted
>> message (one-to-many) achieves the same result.
>
>The problem is that any receiver of a "mute" message has to
>explicitly be able to identify each and every possible source for the
>event.
>
>Suppose I have a four MP3 players, a TV and a home cinema system all
>of which have different target addresses and all of which might be
>required to respond simultaneously to an "audio.mute".
>
>Suppose that an "audio.mute" event can be generated by: a
caller id
>box, an infra-red remote control (ie. manually), by a text to speech
>announcement system (so that the announcement can be heard), and by a
>doorbell interface.
>
>Each of those individual senders has to be configured to send 6
>target messages [OK, I agree that it *may* be possible to target the
>MP3 players with a single message, but the basic principle holds].
>And, worse, if a new device is added to the network, they have to be
>reconfigured. An addiitonal minor niggle is that these messages can't
>be sent truly simultaneously, so there will be fractional delays
>between each device being silenced.
>
>The same argument replies round the other way if you use source
>addressing...
>
>> A many-to-many notification sounds almost like an anonymous
>broadcast.
>> ie no source.
>
>The source is still present, but is ignored. Conceptually I guess you
>could think of it as an anonymous broadcast.
>
>> >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.
>>
>> Isn't that what the subaddress was intended for?
>
>Yes and no. It was the original intention behind subaddressing, but
>it only really works for related functionality. Perhaps the relay
>board is a special case, but the switches and the relays have no
>direct logical or functional relationship - and it doesn't make any
>sense for them to share the same core address.
>
>Patrick