David Mark wrote:
> David Norwood <dnorwood2 <at> yahoo.com> writes:
>> > David H, Lynch Jr. <dhlii <at> comcast.net> writes:
>> >> David Mark wrote:
>> > 1. Change definition of house code O and P commands (eg AO, AP) in
>> > X10_Items.pm. They are currently translated to ON and OFF, while the J
>> > and K
>> > are commented out. This is a strange twist.
>>
>> Actually, O and P are for sending ALL LIGHTS ON and ALL UNITS OFF,
>> respectively. That is why it's in the section that applies to the whole
>> housecode.
>
> I know. But they are attached to "on" and "off" (which are J and K.)
> They
> need their own tokens (eg "allon", "alloff") so that you can create an X10
> item like "A", which has states: "AJ", "AK, "AO", "AP." This is necessary
> to
> support controllers that send "AJ", etc. without a device prefix (implies
> all
> currently addressed devices.)
I see your point and agree. It will break some scripts, but should be
minimal.
>> > 2. Fix cm11 STATUS commands as mentioned before (new parse routine will
>> > not
>> > work with A1STATUS)
>>
>> You should allow for XA1BSTATUS, since the X10 protocol allows for it and
>> someone might want to do it.
>
> You have to for the templincs. That is another reason why A1STATUS, etc.
> is
> invalid.
Agreed.
>> > 3. Fix all other controller modules that send and receive A1J, etc.
>>
>> The reason the CM17 firecracker module omits the second housecode is that
>> the wireless X10 protocol combines the housecode, unit, and function in
>> one
>> command. It's imposible to send XA1BK via RF.
>
> I still say pass and receive in A1AJ form so as not to obscure the mh
> parse
> routine further.
I definetly agree that A1AJ sent to the interface module in two chunks is
preferable to A1J sent in one.
>> > If we can get all of that fixed in the distribution, I will submit the
>> > new
>> > parse code...
>>
>> Are your changes for sending or receiving?
>
> I rewrote the entire section of mh that receives and matches X10 strings.
> The
> main improvement is that it handles mutliple commands bunched together.
> Like
> C2CJA1ASTATUSONF1FK, etc. Once in a while I see things like this show up
> as
> unmatched. There was some really strange stacking of dim commands too.
> Some
> things were removed from the mh layer and left to X10_Items and vice
> versa.
> All in all, the new one is a much easier read for future developers. I
> should
> note that for all its benefits, I am not using it here. I just don't have
> the
> time to test a new X10 engine and have lost interest in keeping the
> logging
> 100% accurate (won't happen with X10 anyway.) The version I use here is
> only
> slightly modified from the distribution. At this point, I know all of its
> quirks and just live with them.
>
> I didn't do much (if anything) to the sending portion of mh. I have made
> additional changes to cm11's send routine. The hack concerning the
> previously
> addressed device has been fixed (so it is no longer a hack.) As I recall,
> it
> was using a static variable to hold the last device and then tacking it on
> to
> status commands.
Your changes sound like an improvement, but should be tested by a few
people.
>> >> Utlimately, the messages have two parts - a target and a command. The
>> >> MH
>> >> X10 interface protocol, sort of diveds that way, but the housecode is
>> >> only relevant in the command, because somewhere just before hitting
>> >> the
>> >> wire something is going to have to add the house code to the command.
>> >> At
>> >> the upperlevels it is only confusing and makes parsing harder, as does
>> >> the odd mix of overlapping commands as strings, commands as singles
>> >> letters ...
>> >
>> > Yes it is a mess.
>>
>> It's just X10, not a misterhouse complexity.
>
> Not exactly. Mh and the various controller modules introduce a ton of
> complexity (at least from my experience with the above-mentioned
> routines.)
Yeah, you're right. Probably the best solution is to document the
"officially supported" X10 commands and then try to keep all the interface
modules in line with that. Right now you have to look at the code to see
which are supported. There is a question in the FAQ about this, but the
answer is incomplete.
Here is a start (from Serial_Item.pm):
if ($serial_data =~ /^([A-P]STATUS)(\S*)/ or
$serial_data =~ /^([A-P]PRESET_DIM1)(\S*)/ or
$serial_data =~ /^([A-P]PRESET_DIM2)(\S*)/ or
$serial_data =~ /^([A-P][1][0-6])(\S*)/ or
$serial_data =~ /^([A-P][1-9A-W])(\S*)/ or
$serial_data =~ /^([A-P]\&P\d+)(\S*)/ or # Pre Dim Cmds
$serial_data =~ /^([A-P]Z\S*)/ or # Scene Cmds for Switchlinc
$serial_data =~ /^([A-P]\d+\%)(\S*)/ or
$serial_data =~ /^([A-P][\+\-]?\d+)(\S*)/) {
>> >> I know why X10 has a plethora of means to do a dim, but why does the
>> >> message stream have to deal with that?
>> >
>> > It shouldn't. The dimming is the messiest and most confusing part of
>> > the
>> > main
>> > parse code. This is compounded by each controller having its own way
>> > of
>> > sending in levels. It makes it really impossible to reliably track the
>> > levels
>> > of the old lamp modules.
>>
>> Aren't there just two ways to do dimming? Relative and absolute (preset
>> dim). That is all my Ocelot module supports. I realize only some X10
>> devices support absolute dimming, and there are a couple ways they have
>> implemented it, but that should be handled higher up by the object for
>> that
>> device.
>
> Yes and no. There are multiple ways to tell mh to dim. At least one is
> cm11-
> specific. In short, L and M, +n, -n and the standard preset dims (&P)
> plus
> the cm11 supports extended preset dims (by turning them into &P commands
> instead of dumping the raw hex into mh.)
The Ocelot supports the lm14a style extended dims also.
>> >> There is plenty of bandwidth between MH and the interface, Create a
>> >> single DIM command, pass the device type, and let the interface figure
>> >> out what the correct X10 way to dim that specific device is.
>>
>> The specific dim command for a particular X10 device should be determined
>> higher up by the object module for that device. All interface modules
>> should
>> support the same set of commands.
>>
>> >> Let me applogize somewhat for the rant above - I am just surely from
>> >> trying to massage all the idiosyncracies of the MH ASCII X10 stream
>> >> into
>> >> a TI103 interface.
>> >
>> > I understand completely. I did a lot of work on the cm11 and w800rf
>> > modules.
>> > The latter hasn't been released as it works slightly differently than
>> > the
>> > original. Might have to make it a new module or something. I found
>> > the
>> > current version of that one to be impossible, but there are people
>> > using
>> > it.
>>
>> My module accepts for sending a housecode followed by either:
>>
>> A unit code 1-9, A-G
>>
>> An X10 function
>> J, # aka ON
>> K, # aka OFF
>> L, # aka Bright
>> M, # aka Dim
>> O, # aka All Lights ON
>> P, # aka All Units OFF
>> ALL_OFF, # aka All Units OFF, reported as P on receive
>> ALL_ON, # aka All Lights ON, reported as O on receive
>> ALL_LIGHTS_OFF, # reported as P on receive
>> EXTENDED_CODE, # posibly ambiguous because E is valid unit
>> HAIL_REQUEST,
>> HAIL_ACK,
>> PRESET_DIM1, # aka Preset Dim 0
>
> I don't understand the aka.
I included this "also known as" because some sources refer to PRESET_DIM1 as
Preset Dim 0.
> EXTENDED_DATA, # posibly ambiguous because E is valid unit
>
> This is Z. Mh won't parse EXTENDED_DATA properly.
I included this for completeness. It's possible to send an EXTENDED_DATA
command without any actual extended data appended. I think misterhouse
should be able to send all 16 standard functions.
>> STATUS_ON,
>> STATUS_OFF,
>> STATUS,
>> PRESET_DIM2, # aka Preset Dim 1
>
> Same as above.
>
>>
>> Relative dim n-times +/-##
>> (I think percentages are converted to n-times by X10_Item)
>>
>
> I can't remember which layer deals with these (in either version.) I
> think it
> has changed in my version.
I guess I should support % as well.
>> Leviton and LM14 style preset dim &P#
>> (this is a special function on the Ocelot. I think it's an extended code
>> X10 command)
>
> &P is an mh syntax meaning preset dim. Cm11 sends/receives these as well.
&P is specific to the lm14a style extended command. Other devices like PCS
dimmers accept standard (not extended) X10 commands like PRESET_DIM1. X10
Item should figure out which command to send to the interface module based
on the 'type' field in the item. I realize the type field isn't used much,
but this is what it's for.
>> see http://www.geocities.com/ido_bartana/toc.htm
|