Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lviper]

Hello all,

Have a little issue going on and I'm not sure what it is. I have this macro that turns a light on when the door is opened during nighttime hours. It has works great for a while, but recently it is only turning the light on at a very low dimmed level. I noticed in the log, when the macro runs, AHP is sending the extended codes in stead of the on command like it used to do. I'm not sure when this started happening but the only thing I've done is upgrade AHP a few times hoping that would solve the issue.

Here is my setup:
AHP 3.311 w/SmartMacros, OnAlert and MyHouseOnline installed.

Front Door has a ds12a that when opened turns oh phantom p1 and sets flag 3
When p1 is on and it's nighttime, f9 turns on. F9 is a ws467.

I have and always had AHP set to send on instead of bright. The macro is set to on. The setup used to always turn the light on and I would see the on command in the activity monitor. But now it sends the extended codes and the light only turns on very dim.

I have installed a couple updates since I've noticed this problem. I think I noticed this around version 3.309. I think that's when I tried the 3.310 upgrade to see if it would fix it. Then I tried 3.311 but still have the problem. I have done upgrades, not delete and full installs which I think is what you all are going to suggest. Oh, and I have tried unplugging the cm15a, remove the batteries and wait 5 minutes. Hooked it back up, downloaded and still have the problem.

Also, I can turn the light on at the wall but it is reset to the lowest dim after ahp sends the extended codes. So I turn the light on then press and hold till I get 100% bright. Tap to turn off and again tap to turn on and it's full bright. I use a palmpad to turn the light on and off and it works as expected. I turn the light on and off from ahp and it works normal. Only time I have the problem is when the macro turns the light on.

Now that I'm writing this, I haven't tried manually running the macro. All I've tried from ahp is turning the actual module on and off. Guess I need to try manually triggering the macro. I may even set a palmpad to HC P do I can trigger the phantom P1 and see what happens. Though I would think it would send the extended codes. I really don't see how the ds10a or ws467a could be the problem, but I've wouldn't overlook it either.

[Brian H]

Are the modules old enough to be before soft start? Where the modules ramp on and off?
AHP 3.11 and a few versions back was updated for the newer soft start modules.
If yours are the older ones there is now a separate list of Before Soft Start Modules in AHP.
Redefine them from the before soft start if they are the older ones.

[Tuicemen]

Just to clarify Brians statement.
Old non softstart light modules must be defined as "Older Lamps (No Softstart)" and not defined as "Lamps" as they were previously!
 

[lviper]

No, the ws467 is a soft start. Ramps up and down.

It did this once before but I forget what version ahp I was running. IIR, it was the first 3.3 version and I just cleared the cm15a, unplugged and removed the batteries. Waited several minutes and hooked it back up and downloaded. Then it started to work correctly again.

[lviper]

I spent some time last night an tried a few things.

If I turn the light on from the module in ahp, it is sending the extended codes. I checked all my ws467a modules and this is the case. Only difference, with the one giving the problem, the extended code is actually sending 0%. If I turn the light on from the palm pad, ahp sends F9 On and the light comes on fully. So I deleted the troubled module, cleared the trash and added a new module. Now the light turns on at 100% but the ahp is still sending extended codes.

Correct me if I'm wrong, but since I have smartmacros set to send ON instead of 100% bright, I shouldn't be seeing extended codes. Is that correct?

[ErikP]

Commands sent from the PC are routed through the X10net service, which automatically translates the ON command into an extended command because it is aware that the module at that address is a module expecting extended codes.  In this case, the macro ON command will be translated into an extended bright command.

Unfortunately the service is unaware of exactly which module the command is meant for so if you have multiple modules at the same address and one of them expects extended codes, all commands sent to that address will be translated.  Double check your recycle bin is clear of old deleted modules too as they are not fully removed until the bin is emptied so they can still cause translation errors.

I think what is/was happening here is that the Soft Start modules are meant to remember their bright state between on and off commands.  For this reason, if the module was dimmed to 0%, then turned off, then turned back on, it would turn on at 0% brightness.  To achieve the old behavior add a 100% brightness absolute command to your macro after the on command.  This will ensure the module is not only on, but at full brightness as well.  Alternatively if you don't plan to ever bright or dim the module just brightening it to 100% then turning it off should set the remembered state so next time you turn it on it should go to 100% bright.

[Noam]

Commands sent from the PC are routed through the X10net service, which automatically translates the ON command into an extended command because it is aware that the module at that address is a module expecting extended codes.  In this case, the macro ON command will be translated into an extended bright command.

Unfortunately the service is unaware of exactly which module the command is meant for so if you have multiple modules at the same address and one of them expects extended codes, all commands sent to that address will be translated.  Double check your recycle bin is clear of old deleted modules too as they are not fully removed until the bin is emptied so they can still cause translation errors.

I think what is/was happening here is that the Soft Start modules are meant to remember their bright state between on and off commands.  For this reason, if the module was dimmed to 0%, then turned off, then turned back on, it would turn on at 0% brightness.  To achieve the old behavior add a 100% brightness absolute command to your macro after the on command.  This will ensure the module is not only on, but at full brightness as well.  Alternatively if you don't plan to ever bright or dim the module just brightening it to 100% then turning it off should set the remembered state so next time you turn it on it should go to 100% bright.

I've seen something similar with my setup.
The problem is that AHP (or the X10nets service) is NOT sending the Extended Code for 100%, but rather for whatever dim level the light was at the last time it was on. It SHOULD not be doing that. If you tell it to turn the light on to 100%, it should do just that - send an extended command for 100%.

[ErikP]

Sending the bright level for the last state is a correct and normal behavior for the new Soft Start modules.

It is a change from the old lamp modules, so requires thinking about things slightly differently, but it is correct in this case.  The idea is that ON and OFF can exist independent of the bright level and be processed without affecting it. 

The main reason for this it is much more flexible with this model than with the old one.  If you want the module on and at a 100% with the new model you send bright absolute 100%.  With the old you send ON.  To turn a module on, but remember its dim status, you send ON with the new model...  I'm not even sure its possible to make a macro to do this with the old model, though I have not spent a lot of time pondering it.

[Noam]

Sending the bright level for the last state is a correct and normal behavior for the new Soft Start modules.

It is a change from the old lamp modules, so requires thinking about things slightly differently, but it is correct in this case.  The idea is that ON and OFF can exist independent of the bright level and be processed without affecting it. 

The main reason for this it is much more flexible with this model than with the old one.  If you want the module on and at a 100% with the new model you send bright absolute 100%.  With the old you send ON.  To turn a module on, but remember its dim status, you send ON with the new model...  I'm not even sure its possible to make a macro to do this with the old model, though I have not spent a lot of time pondering it.

Erik -
I understand your answer, and the "Resume Dim" feature can be useful, sometimes.
However, it isn't the module that is behaving differently, it is AHP and the X10nets service.
If I send an "On" from my HR12A, then the lamp comes on, at full brightness.
Here's the scenario:
I use AHP or the SDK to turn on my lamp at 50%, so I can watch a movie. (timer, macro or whatever).
I then leave the room, and turn the light off with an HR12A.
I then come back, and turn the light back on (to 100%) with an HR12A.
Another SDK function (motion sensor, timer, or whatever) then turns the light back on, expecting it to be at 100%.

If I do the following sequence, Here's what ACTUALLY happens:
1) Turn on lamp using SDK to 50% ("SendPLC C14 ExtCode 31 1F") : Lamp comes on at 50%.
2) Turn lamp off with HR12A: Lamp goes off
3) Turn lamp on with HR12A: Lamps comes on at 100%
4) Turn lamp on again using SDK ("SendPLC C14 On") : Lamp DIMS DOWN to 50%!

This sounds like an issue, since the light had been at 100%, but the SDK/X10nets didn't register that change from the HR12A. If you make X10Nets register that change, then how do you use an HR12A to get the light to full brightness?

[ErikP]

In this case there may be a bug in AHP's recording of incoming commands.  I don't believe it currently considers the ON command to affect the current bright level so it would not remember the 100% bright level unless it recorded a bright/dim command as well. 

In short its outgoing command processing is correct, but is flawed by relying on data from incorrect incoming command parsing.  At least that is my theory as to what is happening in this case.  I will look into the code some more to confirm/fix this.

This should not effect systems which are not receiving commands from outside of AHP.  AHP should always send extended commands to Soft Start modules, unless being translated for the CM19 transceiver.

[Noam]

In this case there may be a bug in AHP's recording of incoming commands.  I don't believe it currently considers the ON command to affect the current bright level so it would not remember the 100% bright level unless it recorded a bright/dim command as well. 

In short its outgoing command processing is correct, but is flawed by relying on data from incorrect incoming command parsing.  At least that is my theory as to what is happening in this case.  I will look into the code some more to confirm/fix this.

This should not effect systems which are not receiving commands from outside of AHP.  AHP should always send extended commands to Soft Start modules, unless being translated for the CM19 transceiver.

Erik -
I understand your explanation, but I'm questioning if the X10nets service should be translating the "On" command into "Bright/Dim to the last level I remember for that module" every single time.
Perhaps we need a separate SDK command for "Resume On," and leave "On" to mean "Turn on at 100%", as it always did in the past, and still does for older modules.

[ErikP]

For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.

[Noam]

For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.

Sounds like a good plan to me.
When the SDK is updated, would it be possible for the "web guys" to make a note of the release date of the new version on the download page? Currently, there is no way to know if the version I have is the same as the one on the download page, or if a newer one was released.

[-Bill- (of wgjohns.com)]

For the SDK this is already in the works.  Its important for the SDK to have an unmodified code path so advanced users can really specify exactly what goes out from the SDK.

The current thinking right now is this will take the form of a "notranslate" flag which will prevent the translation algorithm or anything else form modifying the command away from whatever was specified to the SDK.

By all means, make the flag "notranslate" = true by default!  Otherwise we'll all have to rewrite our software, (that wasn't broken until you changed things), anyway.

[Noam]

By all means, make the flag "notranslate" = true by default!  Otherwise we'll all have to rewrite our software, (that wasn't broken until you changed things), anyway.

I second that!