Posted: May 27 2004 at 16:54 | IP Logged

How can I make them do something like change color when the status changes?

Is there any way to have X10 buttons on more than one tab?

Posted: May 27 2004 at 21:28 | IP Logged

Dean,

I'll answer the second question first...not in this version .  One of the enhancements Im working on is to separate the button definitions from the actual items the button controls and instead make the buttons a child of the tab they belong to.  This will allow you to choose the button type and its action independently of one another.

Now, you can achieve X-10 buttons on multiple tabs.  Just create the buttons as a "Send Keys" button and make the formula perform the desired X-10 action.  Since the formula will be performed as a "send keys", you'll want to surround the X-10 commands with a ph_rtne() function.  An example to turn on a light at A1 is: ph_rtne(ph_x10btn("A",1,2,0)).  I just noticed that the help file for this function is wrong.  Use a 2 for the third parameter to turn a unit "on" and a 3 to turn the unit "off".  You could also use the raw ph_x10 function like so: ph_rtne(ph_x10(1,"A",1,0) + ph_x10(1,"A",102,0)).

First question...It can be done, but it requires you to do it manually with some functions.  A future version of PowerHome is planned where buttons will be flagged as status buttons tied to a global variable or X-10 house/unit where it will be automatic, but were not there yet.

In the meantime, you'll want to check out the functions in the Help file under the "Control Center" section.  In particular, you'll want to look at ph_setccbtnbcolor().  If you were to tie a buttons color to an X-10 device, you'll probably want to make a couple of triggers for the X-10 device on both incoming and outgoing X-10 and execute the ph_setccbtnbcolor() as a result of the trigger.

The only problem with the above, is that the color changes are not permanent and only affect the Control Center within PowerHome.  The color changes will not show up on the web version of the Control Center.  If the Control Center is closed and reopened, any color changes youve made will be lost.

Hope this helps,

Dave.

Posted: June 01 2004 at 12:25 | IP Logged

Dean,

The only problem I see with your computer is the 64k which Im assuming is a typo .  64 meg is still a little weak, but should not cause anywhere near to a 4 to 7 second delay.

Your CASE statement should not be a problem.  When I took your same statement and ran it on my system, it took less than a millisecond.  Below is a macro which you can export and adapt for timing sections of code.  It uses the ph_gettickcount function which accesses an internal timer with millisecond resolution (1000 milliseconds = 1 seconds). 

insert into macroheader values ('000','000',4,4,252,96,0,0,0,12632256,0,0,1,'',10);
insert into macrodetail values ('000',1,15,'[LOCAL1]',NULL,'ph_gettickcount()',0);
insert into macrodetail values ('000',2,15,'[LOCAL3]',NULL,'CASE(now() when 22:00:00 to 23:59:59 then 50 when 00:00:00 to 06:00:00 then 50 else 100)',0);
insert into macrodetail values ('000',3,15,'[LOCAL2]',NULL,'ph_gettickcount()',0);
insert into macrodetail values ('000',4,24,'No TTS',1,'string([LOCAL2] - [LOCAL1])',0);
insert into macrodetail values ('000',5,24,'No TTS',1,'"[LOCAL3]"',0);

Depending upon your current version, the above may or may not import directly, but you should be able to see what Im doing and reconstruct it.  Basically I store the output from ph_gettickcount into a local variable (no database hit as with a global).  Next I perform the action that I would like to have timed...in this case, your CASE statement.  Next I store the output from ph_gettickcount again into a second local variable.  I then send out a messagebox with the difference between the two.  In my case, I had 0 on several tries and got a 1 on 1 try.  You can test this out as well and change the Case statement to a "Delay" command.  When I changed to a Delay command of "1000", I received a difference back of 1002 showing that I had a little performance hit in actually doing the ph_gettickcount functions and the resolution of the delay command not being dead-on.  All in all, this is a handy little way to check timings.

If you check the appendices in the manual, one of them has a listing of the table structures used within the PowerHome database.  In this case, event, info, and sequence refer to columns in the eventlog and weblog tables.  The "event" field is the text explanation of an event in the eventlog table.  "Info" is the text explanation in the weblog table.  In the eventlog report, the information from both the eventlog and weblogs are combined, so you have both fields in the report.  The "sequence" field" is a numeric field in both tables that keep events sequential in the case of multiple events happening so quickly, they are within the resolution of the timestamp field considering them to be the same time.

Concerning your MR26A...I have also built the twinax antenna as well as an eggbeater version.  I have the twinax version located in the attic at one end of the house and the eggbeater version in the attic at the other end of the house.  I combine the signals from both into a signle coax using a standard splitter in reverse.  It works fantastic...even more so now that I use the W800RF32A, but they worked fine when I was using the MR26A.  One possibility that comes to mind are the settings controlling the MR26A in the pwrhome.ini file.  If you open this file and look, you should see a section labeled "[MR26A]".  Underneath this section, there will be 5 parameters.  I'll discuss them below (I believe this is also in the manual in an appendix).

The first parameter is "TimeOut".  When an X-10 RF signal is generated, it is ususally send repeatedly for a specific amount of time depending upon the generating piece of equipment.  The "TimeOut" parameter controls this behaviour and should be set to be just longer than the longest pulse you will receive.  The only way to determine this however though is through trial and error.  In my many tests, Ive found that a value of 500 (this is in milliseconds) seems to work just fine.  If you set this value to low, then a single trip of the motion sensor will appear as two incoming X-10 signals (or more if its really low).  So when testing, bump this value up if a single RF X-10 transmission causes more than 1 trigger to be fired (or event in the event log).  The way this parameter works is thus:  An RF X-10 signal starts to be transmitted.  As soon as the MR26A receives it, PowerHome stores the time of the transmission and immediately fires its trigger (it does not wait for the timeout).  As the RF X-10 signal continues to fire, the MR26A will typically receive about 5 signals.  When the second and subsequent signals comes in, a comparison is made to the housecode/unitcode and function.  If it differs from the first signal, then this is considered the start of a new signal and the process restarts.  If it matches the last signal received, then the current time is compared to the previous time and if within the timeout, then it is ignored. 

The next parameter is "UpdateStatus", this parameter controls whether the incoming RF signals will automatically update the status of X-10 values within the X-10 status table.  Usually you'll want to have this set to "yes", but doing so will cause a slight delay since this is updating the database.

The next two parameters are "Echo" and "EchoController".  Since the MR26A is receiving RF X-10 transmissions, there will not be a corresponding powerline transmission such as would normally exist with a transceiver module such as the TM751.  This is actually a good thing because it minimized the amount of powerline traffic and reduces collisions.  However, some people may want to echo certain RF transmissions to the powerline.  This can of course be done in code with triggers or can be done automatically by setting these two parameters.  If you wish to automatically echo RF transmissions to the Powerline, you'll first have to type in the controller number (1 - 5) of your powerline X-10 device for the "EchoController".  If you are not using this feature then set the "EchoController" to 0.  Next, you want to set the "Echo" parameter to the housecodes which you wish to echo.  If you wanted to only echo housecodes A,F, and G then set the "Echo" parameter to AFG.  By using this feature however, you will increase the response time of your MR26A because now PowerHome is sending commands to the powerline in response to RF commands, perhaps ones you don't even wish to send.  If you are not using this feature, then be sure and set the "Echo" parameter to blank.

The last parameter is "IgnoreCM17A".  If you have a CM17A X-10 RF transmitter controlled by PowerHome, then you typically would not want your MR26A to respond to commands that your CM17A generates.  Set this parameter to "yes" if you have a CM17A controlled by PowerHome so that the MR26A will ignore commands that you send from the CM17A.  Since setting this parameter to "yes" adds a little additional overhead to PowerHome processing...set this value to "no" even if you don't have a CM17A.

And last, PowerHome will not run on Linux .

Hope this helps and keep me posted.

Dave.

Posted: June 09 2004 at 07:26 | IP Logged

Dave,

Thanks for the information.  I don't understand that "insert into macrodetail values ('000',1. . . . . . ." stuff even though I do understand the "gettic" concept.  I havent played much with importing and exporting macros yet.  My maching thinks .psp is a photo shop document.

I think the delay I am experincing is due to bright/dim speed since I almost always dim to zero to eliminate the nuclear flash.  Is there a way to speed up dim commands?

Posted: June 09 2004 at 10:46 | IP Logged

Dean,

Concerning the "insert into macrodetail..." SQL statements...you can just highlight the block then copy and paste the statements in the "Direct SQL" window under the Maintenance window.  These statements will directly add the macro into your database.  It's not too difficult to import and export...understanding the SQL is another matter entirely .

Dimming to 0 and brightening would DEFINATELY do it.  I think you hit the nail on the head.  X-10 is notorious for its lack of speed when dimming and brightening and nothing can be done about it.  I remember reading a technical article a while back which discussed the details of what it takes to send a 100% dim or bright and how many power cycles must occur for the entire message and if I remember correctly, it was somewhere on the order of a little over 3 seconds.

You can however puchase more expensive light switches and modules that have a "soft start" feature.  These lights automatically start at 0 when turned on and ramp up to full brightness as well as ramp down to 0 when turned off.  Some of them even have user definable ramp rates so you can set how quickly or slowly this transition will occur.  These modules and switches also usually support extended dim commands so you can send a single dim command at a specific brightness and have the light go directly to that level.  These commands result in a single powerline transmission rather than the repeated dim or bright commands that must be sent on the powerline for a standard X-10 module.

Dave.

Posted: June 10 2004 at 09:38 | IP Logged

Dave,

Thanks for the info, but what DimPercents in the .ini file for?

BTW I also have a couple of old TV's that "eat" dim bright commands even though ON and OFF get through just fine

Posted: June 10 2004 at 16:32 | IP Logged

Dave, Still having a problem understanding the button color thing. I looked in the sample DB and looked in the user manual and the help file.  I am not understanding the ph_setccbtnbcolor( x, x, x ) formula. TAB i've got. KEY-I don't, and the value I would think would be Hex like #00ff00, right? Maybe if I see an example I would understand it better. Thanx a bunch...

Posted: June 10 2004 at 16:51 | IP Logged

Dean,

The dimpercent value appears several times within the pwrhome.ini file (always under a controller).  Each particular controller's dim and bright commands seem to differ in how many actual commands are placed on the powerline and consequently how much the light actually dims or brightens with a single dim/bright command.  This value is here so a user can fine tune for his controller the percentage a light is dimmed/brightened within the PowerHome status screen. 

For example, using the CM17A RF transmitter combined with a TM751 transceiver, it would appear that going from full bright to full dim happens by sending only 7 individual dim commands.  If you take 100 / 7 you get roughly 14.3 which is the default value for the dimpercent field under the CM17A.  So when you tell PowerHome to send a single dim command using a CM17A, the light will dim to whatever level is actually applied on the powerline by the above combination which in my testing is roughly 14.3%.  This 14.3 percent value is what is reflected in the X-10 status screen.  What Im trying to get across is that the dimpercent in no way affects what is actually sent on the powerline to a light...that is controller dependent.  What the dimpercent is used for is just to update the status internally within PowerHome so that it is close to the real world.

Concerning the dim/bright eating TV's...I think I remember reading about certain commands being more susceptible than others for data loss.  I know they make inline filters that you could buy to keep the TV's from affecting your signals.  I don't remember what they cost however.  Another thing that may help would be a signal amplifier/bridge.  I have a Leviton that I bought from Smarthome that seems to work quite well.  However, in my situation, I had to switch out my main X-10 controller from a CM11A to a PowerLinc since the Leviton kept locking up the CM11A.  This is probably just peculiar to my installation because I havent heard of anyone else having this problem.

HTH,

Dave.

Posted: June 10 2004 at 17:26 | IP Logged

Don,

Yeah...that pesky old "key" value.  This is really an internal value that PowerHome uses to identify a key or button when it is building a Control Center tab.  This number will stay the same until buttons are added or changed on a tab and then it is subject to change.  Basically what happens, when PowerHome is going to build a CC screen, it queries the database for every IR button, every X-10 button, every Macro button, and every Sendkeys buttons that is going to be placed on that particular tab.  I would have to look at the code to see the actual algorithm I used to sort the data, but the "key" number is the numerical order that this button data is gathered.  You probably don't want to hardcode a value for this field because it can change as you change the data or could change in between releases.

Instead, PowerHome provides a function to help you determine a buttons "key" value.  It's ph_lookupccbtn().  You pass this function the button type, the ID, keycode, etc. and it will return the "key" value that the ph_setccbtnbcolor function requires.  A complete example is here:

ph_setccbtnbcolor("TV",ph_lookupccbtn(1,"RCA TV",1,0),rgb(255,0,0))

In the above example, I know what tab the button is on (that's probably not too likely to change. If thats not the case, you can use the ph_lookupcctab function).  In this case it's the "TV" tab.  I next use the ph_lookupccbtn function to get the key value.  The type of button that Im looking up is an "IR" button so the first parameter is 1.  The ID of the IR equipment is "RCA TV".  The key number (not to be confused with "key"), is 1 which is the first button listed under "RCA TV" and what I always make as the "POWER" button.  This key number is the same value that would be used if you were using the ph_ir function.  The last parameter is 0 since this parameter is only used for X-10 buttons.  This ph_lookupccbtn will give me the appropriate "key" value required for the ph_setccbtnbcolor function.  The last parameter is the value that I want to set the color to.  The easiest way to get this is to just use the rgb function.  The value of a color is the sum of its individual Red, Green, and Blue components.  Each component can be from 0 to 255.  Black (the absence of color) would have RGB values of 0,0,0.  White's RGB values are 255,255,255.  The actual formula for combining the RGB values (used by the rgb() function) is:

Red + (256 * Green) + (65536 * Blue)

So, in my example above where I used rgb(255,0,0) to change the background color to red, I could have just hardcoded 255 and gotten the same results.

Good to see you back and HTH,

Dave.

Posted: June 12 2004 at 09:31 | IP Logged

Don,

Ack! , the NEXT version wont remember status...a FUTURE version will .  Just dont want the next version to come out and everyone says...hey! why doesn't it remember button status?

As far as remembering the state, I plan on having some sort of flag so that the user can select whether state is restored or not for that button when PowerHome starts up.  But you're right, for some things you'll definately want to give the user control at startup.

So, I trust youve got your button characteristics changing ?  I'd be interested in everyones use of how they are using these functions within the Control Center so that I can tailor the code that makes the process more automated.

Another thing that Im working on for the NEXT version is some extra triggers that will make this button changing a little easier.  I know some people use the Control Center functions to show global variables.  The next version will have a trigger that is fired when a global variable is changed.  Also, if the Control Center is closed and reopened, you'll lose your state.  I should have a trigger in the next version that is fired when the Control Center is opened.

Let me know how it goes and if you have any other questions.

Dave.

Posted: June 12 2004 at 23:39 | IP Logged

Don't know if I have everything setup correctly for my server. Kinda getting used to WIN32. APACHE server is way different, so here goes a try at it. This link is to show everyone what I was trying to get at how I wanted my powerhome to look. If it doesn't work just email me at dmorenojr@earthlink.net. I will make adjustments. Thanks to Dave I'm just about done with the command center, Now I need to work on the PH Web page. I'm loving it.

http://dmoreno.tzo.com/images/myph.jpg

Posted: June 13 2004 at 14:44 | IP Logged

Don,

Looks great...received the email as well.  The link wasnt working last night but seems to be now.

Thanks for sharing,

Dave.