Print

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

[Brian H]

PowerFlash should not be able to send any Extended X10 codes. I don't think it has that feature in its firmware.

[bkenobi]

I didn't think so.  So, it's either AHP interpreting them wrong for some reason, or interference of some kind damaging them before AHP gets to them.  I wish there was a way to figure this out better since I'm left changing a setting and waiting for enough signals to be transmitted to see an issue or not.  I suppose that's where getting a signal meter comes into play.

[bkenobi]

I lied apparently.  I think I tried setting the PF module up as a Universal module (due to the picture probably) and found that it didn't work.  I currently have it set up as a 2-way appliance module.  I'm going to see what else it can be set up as since it appears there's nothing else that looks good and doesn't have extended codes.  I suppose I can ignore it in AHP and simply let the input pass through to my code (which did seem to work the 1 time I tried it just now).

As for the non-soft start lamp modules, they were set as such (non-SS lamp module).  But, when I went in to edit the module, it was showing the wrong picture.  I can't say that had anything to do with it, but I now have it displaying the right picture and it is sending "A On" rather than "A Bright 100%".  Oh, and I do not have the item selected in the preferences to send "On" instead of "Bright 100%" for macros.

[Brian H]

The Powerflash module is not in AHP as the Powerflash can not receive power line signals to control it.
It is a sender only and you may do better just using the On and Off power line signals it sends to trigger things in AHP.
Trying to define it in AHP maybe the problem. As most devices in  AHP are sent power line signals and not expected to send power line signal back.

[Noam]

The Powerflash module is not in AHP as the Powerflash can not receive power line signals to control it.
It is a sender only and you may do better just using the On and Off power line signals it sends to trigger things in AHP.
Trying to define it in AHP maybe the problem. As most devices in  AHP are sent power line signals and not expected to send power line signal back.

I'll echo what Brian said.
As far as I know, with the exception of motion sensors, all of the devices that are available to pick on AHP are devices that can receive a signal. My theory is that the motion sensors are in there to allow you to name them and use that for monitoring through the Activity Monitor.

Since the PowerFlash can only send a signal, there is no reason to list it in AHP. You can't list any of the wired or wireless remotes, either.

AHP and the CM15A don't know what type of device is sending those commands on the powerline, and they don't really care.

Unless you have something else on the same HC/UC as the PowerFlash (like a lamp that it directly controls), there is no need to have it in AHP at all.
If you want to be able to view the status of it in AHP easily, you can create a "dummy" appliance module (one-way) on the same HC/UC.

[bkenobi]

I understand what you are saying in regards to AHP having no need to list items it can't control.  However, there are several items in the module list (other than motion sensors) that AHP can't do anything with.  I looked in there yesterday and found several camera palm pad controllers and the like which don't seem to be needed either.  I primarily had it there so I could have a visual indication to what's being triggered in the AHP interface, but I also thought it might be needed for the SDK to send the commands through.  Since it is not, there's really no need to list it.

Oh, and I like having the motion sensors in there so I can see what's been triggered with a name attached in the list.  It also helps plan a system because they show up in the "find computers" list (btw, shouldn't that be named "find modules"?).  In that regard, I don't think they are useless.  If there is a menu available to show you what HU are in use, then it should be possible to name that item IMO.

I checked the logs this morning and it appears that the motion sensor worked just fine last night.  There were significantly fewer triggers last night, so adjusting the aim of the sensor does seem to have helped as well.  As for the A7 modules, I just realized that the reason they send a "Bright 100%" command is that they are triggered by a macro and by default macros send that instead of "On".  I posted that earlier but it didn't connect in my head as to what it really meant.   

[Noam]

I didn't see any of the remotes, but I don't have the video plugin activated on this machine.
I agree that it is helpful to list the motion sensors, to be able to see where a command is coming from, and what HC/UC are in use (although if you have a macro on one of those codes, it will be listed in the "find other computers" screen).
As I suggested earlier, you can monitor the status of the Powerflash with a simple "dummy" appliance module (a one-way, not a two-way), set to the same HC/UC as the Powerflash. Call it "PowerFlash" if you want. When those codes come in, it should turn on and off (on screen), and you'll see it listed as a receive code in the Activity Monitor.

However, whatever you are triggering with that HC/UC will also be listed, so adding the appliance module might be overkill. That's you to decide.

One other thing (and it is listed in the Bug List - see my signature for the link): Currently, the SDK will "translate" outgoing old-fashioned "on" commands into "Extended Dim" commands for lights which are defined in AHP as SoftStart capable modules. I ran into this myself. I was using AHCMD to send something like "C5 On", and it was actually sending "C5 ExtCode 31 3f" (Which is the Extended Dim version of "turn on at 100% immediately - without SoftStart). When I changed the module definition in AHP to an "old" style lamp, it started sending the correct "On" command (as I recall, at least).

[bkenobi]

Interesting info about the bug.  I was concerned initially that not having the PF in AHP would be an issue.  Once I realized it would still send the command through without processing it, I started to get concerned what module would not mess with the signal on the way by.  I have a bunch of dummy modules I use for seeing flags on the interface.  I may try adding one for the PF if the current setup does continue to perform correctly.

[bkenobi]

I came home on Saturday and found the lights turned on.  This is the reason I was initially investigating this in the first place, so it appeared that things were still AFU.  Well, after reviewing the log and the code, I found a small bug on my end.  It looks like if there is motion just before dawn, the code would turn off the motion delay timer and the lights, but it neglected to disable a key flag I use to designate whether the motion delay is enabled.  As such, when the CM15A told my code that it was dusk, the code would think the motion delay was still on and turn the lights back on.  Since there was no motion, it would leave the lights on until there was motion and then it would turn them off after the motion delay expired.

So, one seemingly innocuous line of code caused me to go through all this.   

Meh, it did force me to do a really thorough review of ALL of the code and the entire hardware setup.  So, it's not all bad, but I think the WAF for the project on a whole may have slipped slightly.   

[Noam]

So was that one misplaced line of code the cause for all of the issues, or were there other contributing factors?
Are there still any problems you need to resolve with this setup?

[bkenobi]

The original issue was that the lights were on when I came home and the log didn't indicate that motion had been seen at the right time to turn those lights on.  I started making changes that exacerbated the issues into the mess that my original post posed.  There are several lessons learned here, though.

• The motion sensor aim is very important to understand.  Zenith will tell you what the down angle is, but they do not list the up angle.  Through experimentation, I can say that it can see slightly upward from horizontal.
• The relay seems to work very reliably even when triggered hundreds of times a night (though not ideal for longevity of the system).
• The Powerflash does not need to be in AHP in order for the signals it sends to pass through to the SDK.  There may be a module in AHP that will allow for the signals to be passed through unaltered, but I did not locate one with my limited testing.
• Although I thought I had been very careful in documenting my code such that errors were not likely, I was able to find a handful of coding missteps that caused this (one missing line) and would likely have caused other problems down the road.
• Even when the project is done, it's never really done!

I think this problem is resolved, but I'll continue to monitor the performance to verify proper operation.  The reason I just started seeing this issue is that sunrise happens to fall right after my wife leaves for work at this time of the year.  I suspect that had I not gotten this resolved I would not have noticed this issue again until next fall.  This would have probably mysteriously disappeared in another couple weeks when sunrise happened before my wife leaves.

[bkenobi]

So far, so good!  I'd call this resolved.

Thanks all!   

[bkenobi]

 

I walked outside this morning to clean the clogged gutters and the light didn't turn on for me.  I reviewed the log just now and found that it's still having issues on the order of 6% of the time.  I'm going to have to try the XPF to see if that helps.  I also had one of my ActiveEye's not respond, but I'm thinking it might be related to getting wet.  It's located on the south side of the house and it was really stormy last night through this morning (hence cleaning the gutters), so I suspect there was a lot of driven rain that may have seeped inside the case.  Last time I had this issue, I brought it inside to dry out and changed the batteries.

Btw, how long do MS16A's work on a single set of batteries?  I know we have motion on that side of the house from wildlife and possibly just the trees.  I replaced batteries ~1 month ago, so I'd be disappointed if they already failed.  I suppose I could use a different motion sensor in that location mounted directly to the light fixture...

[bkenobi]

I modified my motion sensor code for those MS16A units so that I can tell which one is sensing motion.  Before, I just set them both to the same HU code and used the ON signal to trigger the motion delay code.  It's obvious if it's working if I walk outside, since they are quite a ways apart.  However, if they trip at night, I don't know which one was sending the code.  If it's the same one, that would explain the poor battery life!

If I have time this weekend, I'm thinking I'll have to unplug all of the signal sucker/noise generators that I can to see if I get more reliable performance.  The issue is still that I can't cause unreliability on a whim.  Of course, if I could do that, I'd know what to fix.   

[bkenobi]

Well, I still haven't figured out why I'm losing signals yet.  I didn't have a chance to check with and without certain things plugged in, so I opted to modify the code for now.  Since I can't rely on both ON and OFF being received, I changed the code so it looks for either ON or OFF and just sets the delay timer when either is seen.  I'll try to get things more reliable, but this will work for now.