Re: Hardware embedded BSC Mapper

["darrenp_lock" <darrenlock@xxxxxxx>]

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=20
period after triggering (1 min I think is the shortest). When I get=20
an ON from the detector I turn on the lights and start a timer. When=20
the timer expires it turns OFF the lights. I ignore the motion OFF=20
which expires earlier. The reason I set the trigerring so low is so=20
that the timer gets re-triggered as frequently as possible such that=20
the light never goes off unless there has been no further motion=20
detected since the timer was last triggered (btw I set my timer for=20
about 6 mins). I don't use the motion dector timer because it=20
doesn't re-trigger whilst it is on. This anoys the wife as the light=20
will go OFF then not come back ON again until she does a dance in=20
the room.

Thre reason for e) is to only do the above when the Darkness sensor=20
is ON.

Rgds, Darren.
--- In xap_automation@xxxxxxx, Kevin Hawkins <lists@...>=20
wrote:
>
> Hi Darren,
>=20
>     Thanks for the input - here's some comments
>=20
>     a) Yes you can do that already
>=20
>     b) Never thought anyone would want that but not difficult -=20
what=20
> would you use it for ?
>=20
>     c) That's a useful one
>=20
>     d) I do handle level mapping at the moment ie map 60% to 60%=20
(or 60%=20
> to 40% if inverted). Setting up ranges for mapping would be fairly=20
> complex - again what would the application be for this ?
>=20
>     e) That's the bit in the 'logic engine' I mentioned. The=20
problem=20
> here is that a complete implementation rapidly becomes complex and=20
it is=20
> awkward to provide a nice configuration interface from such a=20
small=20
> device - there is no script language that a user would have access=20
to.=20
> I'm still thinking on this though.  Currently I do do this myself=20
but my=20
> logic is hardcoded into the C firmware.=20
>=20
>         Already I keep a state information table for any devices=20
that=20
> requires display via the web interface.  Anything that eats memory=20
is a=20
> problem so retaining text or displaytext values is problematic .=20
Setting=20
> up arrays with reserved space that store this per device is very=20
> inefficient and I am still early days in my C familiarity. I am=20
already=20
> playing with ways of storing this text separately and only for the=20
> length of data required.  One other possibility is that maybe I=20
can do=20
> away with storing them at all and issuing BSC.query commands as=20
needed=20
> to read current values. Holding state and level information can be=20
done=20
> very compactly. UDP and string buffers, Text and source addresses=20
are=20
> the memory guzzlers.
>=20
>     Kevin
>=20
>=20
>=20
>  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=20
only
> > map Dim and Bright commands
> > c) Timer function e.g. BSC Input On maps to BSC Output On=20
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=20
On
> > then BSC Output A On (recognise that this would mean tracking=20
device
> > state)
> >
> > Food for thought?
> >
> > Rgds, Darren.
> > --- In xap_automation@xxxxxxx=20
> > <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=20
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=20
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=20
for
> > a
> > > target price around =A350. (there will be no serial port on
this
> > > device). I actually have this mostly running here already=20
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=20
constructive
> > > input. I have a few ideas based on my own xAP setup here but
I=20
am
> > keen
> > > to keep basic simplicity of function and required string=20
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=20
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
> > >
> >
> >
>






=20