Re: Re: Hardware embedded BSC Mapper

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi Darren,

I can see a few people might have a use for (b) - implemented as a
'non cancellable resettable' timer perhaps which would avoid the OFF
trigger turn it off, although another BSC cmd  could turn it off if and
as needed.

(e) would be much easier to accomplish as a standard conditional for
the mapping ie . Map A to B only if C is ON.  Then the darkness sensor
would have to report a state= within the BSC block based on whether it
was 'dark' or not  . Within BSC State and Level are not always
restricted to Level=0 equates to OFF and everything else is ON.  On a
256 level device you could have Level 0 to say 110 as OFF and 111 - 255
as ON  and then the 'is dark' becomes a binary condition which is far
easier to test in limited space.  Whatever way we do this any
conditional logic would be a future product or software update.
Interestingly even when you introduce such a simple logical connection
you immediately get ambiguities and complications. What for example
would happen when A and B are different but C then becomes true/ON -
should it enforce the map and change B's state or not ?  As you can
imagine as the permutations grow simple interactions can become very
complex - hence the usual approach of a script language - which is more
than this could ever offer.

Kevin

.darrenp_lock wrote:
>
> Hi Kevin,
>
> my reason for b) is the ongoing issue of motion detectors:
>
>
> I currently set my motion detector to come on for the smallest
> period after triggering (1 min I think is the shortest). When I get
> an ON from the detector I turn on the lights and start a timer. When
> the timer expires it turns OFF the lights. I ignore the motion OFF
> which expires earlier. The reason I set the trigerring so low is so
> that the timer gets re-triggered as frequently as possible such that
> the light never goes off unless there has been no further motion
> detected since the timer was last triggered (btw I set my timer for
> about 6 mins). I don't use the motion dector timer because it
> doesn't re-trigger whilst it is on. This anoys the wife as the light
> will go OFF then not come back ON again until she does a dance in
> the room.
>
> Thre reason for e) is to only do the above when the Darkness sensor
> is ON.
>
> Rgds, Darren.
> --- In xap_automation@xxxxxxx
> <mailto:xap_automation%40yahoogroups.com>,
Kevin Hawkins <lists@...>
> wrote:
> >
> > Hi Darren,
> >
> > Thanks for the input - here's some comments
> >
> > a) Yes you can do that already
> >
> > b) Never thought anyone would want that but not difficult -
> what
> > would you use it for ?
> >
> > c) That's a useful one
> >
> > d) I do handle level mapping at the moment ie map 60% to 60%
> (or 60%
> > to 40% if inverted). Setting up ranges for mapping would be
fairly
> > complex - again what would the application be for this ?
> >
> > e) That's the bit in the 'logic engine' I mentioned. The
> problem
> > here is that a complete implementation rapidly becomes complex
and
> it is
> > awkward to provide a nice configuration interface from such a
> small
> > device - there is no script language that a user would have
access
> to.
> > I'm still thinking on this though. Currently I do do this myself
> but my
> > logic is hardcoded into the C firmware.
> >
> > Already I keep a state information table for any devices
> that
> > requires display via the web interface. Anything that eats memory
> is a
> > problem so retaining text or displaytext values is problematic .
> Setting
> > up arrays with reserved space that store this per device is very
> > inefficient and I am still early days in my C familiarity. I am
> already
> > playing with ways of storing this text separately and only for
the
> > length of data required. One other possibility is that maybe I
> can do
> > away with storing them at all and issuing BSC.query commands as
> needed
> > to read current values. Holding state and level information can
be
> done
> > very compactly. UDP and string buffers, Text and source addresses
> are
> > the memory guzzlers.
> >
> > Kevin
> >
> >
> >
> > darrenp_lock wrote:
> > >
> > > Kevin,
> > >
> > > at that price I would be very interested. Aware of the space
> > > limitations, if it could replace my current PC based
solution it
> > > would have to support the following:
> > >
> > > a) Map 1 BSC Input to many BSC Outputs
> > > b) Mask BSC Input commands i.e. may only map On but not Off
or
> only
> > > map Dim and Bright commands
> > > c) Timer function e.g. BSC Input On maps to BSC Output On
> followed
> > > by BSC Output Off after a period of time. (Note BSC Input
Off is
> > > ignored if b above could be done)
> > > d) Level mapping e.g. if BSC Input Level greater than, equal
to,
> > > less than then map to BSC Output Command/Level
> > > e) Conditional maps e.g. If BSC Input A is ON and BSC Input
B is
> On
> > > then BSC Output A On (recognise that this would mean
tracking
> device
> > > state)
> > >
> > > Food for thought?
> > >
> > > Rgds, Darren.
> > > --- In xap_automation@xxxxxxx
> <mailto:xap_automation%40yahoogroups.com>
> > > <mailto:xap_automation%40yahoogroups.com>,
Kevin Hawkins <lists@>
> > > wrote:
> > > >
> > > > I am looking at releasing an Ethernet connected
embedded
> > > controller that
> > > > will allow 'mapping' of xAP BSC devices. For example an
input
> or
> > > output
> > > > on BSC device A controls an output on BSC device B. An
example
> > > > 'mapping' might be Netiom input to a C-Bus / X10 light
perhaps.
> > > This
> > > > would mean xAP BSC devices can be interconnected 24/7
without
> any
> > > PC
> > > > and software being required.
> > > >
> > > > The device I'm guessing would hold over 50 such
mappings and be
> > > > configurable via a web interface and maybe a xAP schema
too. It
> > > would
> > > > support inverted mappings and wildcarded targets. I am
hoping
> for
> > > a
> > > > target price around £50. (there will be no serial
port on this
> > > > device). I actually have this mostly running here
already
> based on
> > > > stripping the C-Bus code out of my existing C-Bus xAP
gateway.
> > > The
> > > > to-do's are mainly configuration and web pages.
> > > >
> > > > Whilst refining this if anyone has any thoughts on
other
> > > features /
> > > > ideas they might like to see included I would welcome
> constructive
> > > > input. I have a few ideas based on my own xAP setup
here but I
> am
> > > keen
> > > > to keep basic simplicity of function and required
string
> storage
> > > as
> > > > small as possible as well as no additional hardware
ports.
> > > Reliability
> > > > is a primary consideration. The devices' firmware will
be field
> > > > upgradeable so I can add things later (and fix any
gremlins).
> > > Initially
> > > > probably just mapping and web display/config will be
provided.
> > > >
> > > > So fire away..... some thoughts so far on extra
features...
> > > >
> > > > A BSC device display and control webpage for any BSC
devices
> you
> > > may have
> > > > AJAX based realtime browser updates
> > > > xAP Intranet enabled
> > > > Configurable by xAP messages to report/add/remove
mappings
> > > >
> > > >
> > > > ...and more ambitious...later updates... if space
permits
> > > >
> > > > Time (clock) broadcasting
> > > > Groups and Scenes engine
> > > > Basic BSC scheduler functionality eg timed / periodic
BSC cmd's
> > > > Logic functionality , if..then etc (complex &
unlikely to be
> > > enough space)
> > > > .. transition to a xAP BSC controller/engine
> > > >
> > > > Kevin
> > > >
> > >
> > >
> >
>
>