X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Topic started by: Noam on November 04, 2010, 09:13:09 AM
-
It looks like X10 released a new update to ActiveHomePro this morning.
Here are the release notes for version 3.296:
* Bug fix: Secure Commands not being shown in Activity Monitor
* Filter out unknown command caused by transceiver initialization
* Altered behavior of missing transceiver pop-up for simple video bundle
* Fix for possible crash when opening Activity Monitor with empty history
Well, hiding some of the "garbage" some of us were seeing was good (for those that don't want to see it), but I no longer have an indicator of when my CM15A is re-initializing itself (which it was doing several times a day, with no explanation so far).
-
lol: i uninstalled everything and cant get past installing ahp 296 without it crashing. Even after cleaning out my reg.
I shoud have waited. lol
Update: I was able to uninstall then do a restore back to yesterday and now i am fine. That was fun. NOT.
-
The email send out still not being fixed.
After a reboot, an email sent out by AHP still showing default sender: AHPGateway@x10.com.
Why is it not saved with my setup?
Yet, it will send out with my setup ONLY after I go to email confg. And it goes back to default setting again after AHP/computer reboot.
P.L
-
@phongluu
Are you making the change in the Config while AHP is closed?
-
I changed at My house tab>Email Config on the AHP main MENU.
I dont think we can change it while AHP close, cannt we? ...well...unless doing regedit.
Do you know a way?
Thanks,
P.L
-
@phongluu
C:\Program Files\ActiveHome Pro\
I think it's called emailconfig.XML or similar. Open it with Notepad.
-
I'm looking into the emailprp.xml, all of the email add in there is my config. Non showing AHPGateway.
Again, it's still showing AHPGateway as a sender on email after reboot.
Thanks,
P.L
-
OK, after few hours of testing new version 3.296: there are still ton of M MTCDDVD receive RF in my Activity Moitor.
It looks like everytime the Sensor Closed feedback, it give that M MTCDDVD twice.
grrrrr
P.L
-
With all the negative posts it sure appears to me 3.296 goes right into the bad release file of AHP with 3.236. Makes me glad I don't use any plug-ins. Don't need any one.
-
Actually 3.296 is working much better than several of the last builds.
The M MTCDDVD command was also showing up in my activity monitor last night until I did a bit of testing.
This was happening with 2 MS10As and oddly enough, once I changed their security codes several times, reinstalling the sensors to AHP each time to test, eventually it stopped.
Almost seems AHP doesn't like certain security codes from devices, or something is being corrupted during updates.
It doesn't seem to cause any issues other than making navigating the log file a bit of a pain.
Either way, 3.296 has fixed several issues I had seen using the last 3.295 build, so it's a step in the right direction IMO. >!
-
With all the negative posts it sure appears to me 3.296 goes right into the bad release file of AHP with 3.236. Makes me glad I don't use any plug-ins. Don't need any one.
Dan - Perhaps users who are having problems with 3.296 simply need to do a complete uninstall and fresh reinstall to fix the instability. ;-)
-
This was happening with 2 MS10As and oddly enough, once I changed their security codes several times, reinstalling the sensors to AHP each time to test, eventually it stopped.
the M MTCDDVD commands are actually valid security commands which are correctly stored in your history, but the monitored security code is not functioning properly, and this causes the Activity Monitor window to parse them incorrectly. The bug that was introducing the problem was fixed in 296, but that doesn't remove it from all affected systems. The problem can be fixed by overwriting the monitored security code by removing your secure modules and adding them back in. You shouldn't need to change change the codes on the devices. When you overwrite the bad code, the next time your history is built the M MTCDDVD will be read properly for what they are and displayed as security commands in the log. If you change the codes, then the events in your history will no longer be on a monitored security code and will not be written to your Activity Monitor.
This is working on all of the tests systems which encountered this error, but definitely let me know if you are seeing something different.
-
I have run this version 3.296 over a night and some of my Macro trigger for some no reasons due to a Security sensor.
Looking at the log, for 1 minute, the sensor has more than 15 feedbacks: triggered, closed, M MTCDDVD.
And I'm 100% sure the sensor didnt open or close at night otherwise my DS7000 would go into alarm and wake everyone up.
Please fix this.
In addition, it would nice for someone to look into why on a Macro that using Securiy sensor a trigger then using condition (time range, day range, flag status) would NEVER work. Instead, it just can only turn on a dummy device than using that device to trigger with conditions.
Thanks,
P.L
-
Looking at the log, for 1 minute, the sensor has more than 15 feedbacks: triggered, closed, M MTCDDVD.
And I'm 100% sure the sensor didn't open or close at night otherwise my DS7000 would go into alarm and wake everyone up.
Have you removed and re-added the secure devices? I didn't see it happen in my testing, but its possible the same thing causing the M MTCDDVD to appear in the first place is causing extra commands to appear in the log as well. Is anyone else seeing extra unexplained security commands in their Activity Monitor?
-
When I was getting the M MTCDDVD show up it was along with the proper MS10A triggered command.
It stopped for me when I changed the security code on the MS10As several times while reinstalling the sensor to AHP each time.
Then I would trip the sensor to see if was still displaying M MTCDDVD.
I didn't actually delete the module from AHP as far as I remember.
-
I have about 20 sensors: half of them giving me trouble.
Do I really have to re-install all and test each to make sure no more M MTCDDVD?
I'm gonna do it one by one, starting by most critical....yet, is there a fix?
Thanks,
P.L
-
I didn't actually delete the module from AHP as far as I remember.
The method you used should also work, though I did not test it myself. As long as the corrupted security code entry gets overwritten with a correct value is the important part.
I'm gonna do it one by one, starting by most critical....yet, is there a fix?
Unfortunately no :(. The corruption is just incorrect security codes being stored for some modules. The codes are valid, just not correct. There is no way the software can know what code is correct other than you telling it what is correct, which is what re-adding the module or changing the security code does.
-
Ok, tried to reinstall few sensors and ran for a day. They are still giving a lot of M and (perhaps) misfire Macros again last night. Dawn it!
Was previous version better? Or I don't recall seeing a lot of M craps in the even log and misfire the macro to send me txt msg in middle of the night!
P.L
-
I beleive that this version also has bug with Dusk and Dawn timer.
None of my Timer trigger after the clock change last weekend.
Also, would anyone looking into the bug where sensor NOT triggering a macro with conditon, please? (Email using Onalert)
P.L
-
They are still giving a lot of M and (perhaps) misfire Macros again last night.
There does appear to be some M MTCDDVD commands appearing in the log still. It is extremely rare in the test systems however (twice in almost a week of running multiple systems) so it will probably take some time to track down the cause on my end. Any information you can give me will help me find the bug :)
Is there a pattern when you see these in your log? For example do you still see them every time certain door/window sensors are triggered?
Does the M MTCDDVD have a time stamp after the entry below it, or before the entry above it?
I believe that this version also has bug with Dusk and Dawn timer.
None of my Timer trigger after the clock change last weekend.
There was an old bug where if the system time was changed back in time, such as falling back, it would mess up the timers for a bit. Restarting the X10net service and re-syncing the hardware was a workaround for this at the time. This should have been fixed, but I will take a look at it and make sure it didn't get broken again somehow.
Also, would anyone looking into the bug where sensor NOT triggering a macro with condition, please? (Email using Onalert)
This appears to be working on all my test systems. Can you send me a copy of your ahx file, or post an image of your macro that’s not working in the editor?
-
I to see M MTCDDVD commands which seem to be right after a particular security motion sensor trips or resets.
I replaced the batteries and the signals stopped occurring but now I'm getting them after a different sensor (Not a motion sensor) I thought these modules were suppose to show in AHP when batteries were failing? ???
Is the check for new release fixed with this version? (not working since 3.228)
Update to interface fails from the hardware configuration screen.
-
I thought these modules were suppose to show in AHP when batteries were failing? ???
In my short experience with X10 (1.5 months), that is still the case. The M MTCDVD commands are unrelated (as seen in other threads and posts by Erik P and AHP Dev).
Is the check for new release fixed with this version? (not working since 3.228)
Still not working (as far as we know). The updates have been consolidated, so you only need to download the ActiveHome Pro file from the Support site, and it will update all the plug-ins you have at the same time. The separate installers are only if you're adding a plug-in for the first time.
Update to interface fails from the hardware configuration screen.
Haven't run into that yet. CM15A?
-
M MTCDDVD here seems random - could be after a security sensor triggered, but definitely comes 1 sec to 20 MINUTES after it.... so I question it totally coming from DS10s here,
My emailing text to cellphone after DS10 trigger AND if FLAG 1 ON has been working since like 3.27x so not sure why some folks dont. Unless your condition is DUSK, dawn,day, nite - they havent worked for me for a couple years; why I set/clear flag 1 based on timer of a lite sw instead.
-
This is what I see for the MTCDDVD entries - here is a short sample of a log riddled with them and the A 00TV codes. They are almost always around door sensor or motion sensor events. If it matters, besides the CM15A, CM19A, and VA12A for video, I have an RR501 near the computer, a TM751 a floor up from the computer, an SR731 in the house near the TM751 and an XPCR in a circuit box next to the main breaker box bridging the two legs of my electric service.
734 11/15/2010 9:45:54 PM Receive RF M MTCDDVD
735 11/15/2010 9:45:54 PM Receive RF A 00TV
736 11/15/2010 9:45:54 PM Receive RF M MTCDDVD
737 11/15/2010 9:45:54 PM Receive RF Bookcase MS10A #7 - Motion Reset
738 11/15/2010 9:45:54 PM Receive RF A 00TV
739 11/15/2010 9:45:54 PM Receive RF Bookcase MS10A #7 - Motion Reset
740 11/15/2010 9:45:54 PM Receive RF A 00TV
741 11/15/2010 9:45:54 PM Receive RF Bookcase MS10A #7 - Motion Reset
742 11/15/2010 9:45:54 PM Receive RF A 00TV
743 11/15/2010 9:45:54 PM Receive RF Bookcase MS10A #7 - Motion Reset
744 11/15/2010 9:45:54 PM Receive RF A 00TV
745 11/15/2010 9:45:54 PM Receive RF Bookcase MS10A #7 - Motion Reset
746 11/15/2010 9:45:54 PM Receive RF M MTCDDVD
747 11/15/2010 9:45:54 PM Receive RF M MTCDDVD
748 11/15/2010 9:45:55 PM Receive RF A 00TV
749 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
750 11/15/2010 9:45:55 PM Receive RF Bookcase MS10A #7 - Motion Reset
751 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
752 11/15/2010 9:45:55 PM Receive RF A 00TV
753 11/15/2010 9:45:55 PM Receive RF Bookcase MS10A #7 - Motion Reset
754 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
755 11/15/2010 9:45:55 PM Receive RF A 00TV
756 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
757 11/15/2010 9:45:55 PM Receive RF Bookcase MS10A #7 - Motion Reset
758 11/15/2010 9:45:55 PM Receive RF A 00TV
759 11/15/2010 9:45:55 PM Receive RF Bookcase MS10A #7 - Motion Reset
760 11/15/2010 9:45:55 PM Receive RF A 00TV
761 11/15/2010 9:45:55 PM Receive RF Bookcase MS10A #7 - Motion Reset
762 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
763 11/15/2010 9:45:55 PM Receive RF M MTCDDVD
I have not removed all the security sensors and re-added them, but I will give that a try. I just don't want to generate new codes or else I have to totally reset my DS7000 and that's a pain.
Kevin
-
kevinwheeler
In my case simply replacing the batteries for the sensor that was showing a status prior to the Receive RF M MTCDDVD signal fixed the error.
anthonylavado
the battery indicator shows when the sensor fails to send any info such as dead batteries.
in my tests the worse the batteries in the sensor the more RF M MTCDDVD seen.
New Batteries don't always mean good ones!
Of coarse my units are all older and it may be just a fluke that it was a battery issue but when it happens more then once the chances of a fluke go down.
ErikP
One other long time bug that you may wish to look into is the windows command macro options bug.
The thing is if you create one it works fine.
but if AHP shuts down via a PC restart or you restart AHP manually the macro will fail when AHP reopens.
However if you create another windows command macro then all macros with a windows command work until a AHP restart.
I have a work around posted Here (http://forums.x10.com/index.php?topic=15010.msg83769#msg83769) to get by this bug but many users are uncomfortable with writing scripts (no mater how easy)
-
Also, would anyone looking into the bug where sensor NOT triggering a macro with condition, please? (Email using Onalert)
This appears to be working on all my test systems. Can you send me a copy of your ahx file, or post an image of your macro that’s not working in the editor?
[/quote]
Try using a door sensor TRIGGER a macro that SENDING email with CONDITION: during business hour. It will not work.
-
They are still giving a lot of M and (perhaps) misfire Macros again last night.
There does appear to be some M MTCDDVD commands appearing in the log still. It is extremely rare in the test systems however (twice in almost a week of running multiple systems) so it will probably take some time to track down the cause on my end. Any information you can give me will help me find the bug :)
Is there a pattern when you see these in your log? For example do you still see them every time certain door/window sensors are triggered?
it seems like all of them giving me the M MTCDDVD even after reset it. I can send you a log if needed.
Does the M MTCDDVD have a time stamp after the entry below it, or before the entry above it?
Yes, it does.
I believe that this version also has bug with Dusk and Dawn timer.
None of my Timer trigger after the clock change last weekend.
There was an old bug where if the system time was changed back in time, such as falling back, it would mess up the timers for a bit. Restarting the X10net service and re-syncing the hardware was a workaround for this at the time. This should have been fixed, but I will take a look at it and make sure it didn't get broken again somehow.
I tried it : reboot comp, reset/clear/reload CM15A, still didnt work.
Also, would anyone looking into the bug where sensor NOT triggering a macro with condition, please? (Email using Onalert)
This appears to be working on all my test systems. Can you send me a copy of your ahx file, or post an image of your macro that’s not working in the editor?
I can send you my ahx file. Email? or PM? Thanks
-
FYI, this is within on emitute of my log:
608 11/16/2010 11:08 Receive RF A 00TV
609 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Detected
610 11/16/2010 11:08 Receive RF A 00TV
611 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Detected
612 11/16/2010 11:08 Receive RF A 00TV
613 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Detected
614 11/16/2010 11:08 Receive RF A 00TV
615 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Detected
616 11/16/2010 11:08 Transmit E12 (F.Gara.M.Phantom)
617 11/16/2010 11:08 Transmit E On (F.Gara.M.Phantom)
618 11/16/2010 11:08 Macro B1 (B1.Front.Chime)
619 11/16/2010 11:08 Macro B On (B1.Front.Chime)
620 11/16/2010 11:08 Macro E12 (F.Gara.M.Phantom)
621 11/16/2010 11:08 Macro E Off (F.Gara.M.Phantom)
622 11/16/2010 11:08 Macro E12 (F.Gara.M.Phantom)
623 11/16/2010 11:08 Macro E Off (F.Gara.M.Phantom)
624 11/16/2010 11:08 Receive RF A 00TV
625 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Reset
626 11/16/2010 11:08 Receive RF A 00TV
627 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Reset
628 11/16/2010 11:08 Receive RF A 00TV
629 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Reset
630 11/16/2010 11:08 Receive RF A 00TV
631 11/16/2010 11:08 Receive RF 16.F.Gara.Motion - Motion Reset
632 11/16/2010 11:08 Receive RF A 00TV
633 11/16/2010 11:08 Receive RF M MTCDDVD
634 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Triggered
635 11/16/2010 11:08 Receive RF A 00TV
636 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Triggered
637 11/16/2010 11:08 Receive RF A 00TV
638 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Triggered
639 11/16/2010 11:08 Receive RF A 00TV
640 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Triggered
641 11/16/2010 11:08 Receive RF A 00TV
642 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Triggered
643 11/16/2010 11:08 Receive RF M MTCDDVD
644 11/16/2010 11:08 Receive RF M MTCDDVD
645 11/16/2010 11:08 Transmit E1 (1.F.Door.Module)
646 11/16/2010 11:08 Transmit E On (1.F.Door.Module)
647 11/16/2010 11:08 Receive RF A 00TV
648 11/16/2010 11:08 Receive RF M MTCDDVD
649 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Closed
650 11/16/2010 11:08 Receive RF A 00TV
651 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Closed
652 11/16/2010 11:08 Receive RF A 00TV
653 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Closed
654 11/16/2010 11:08 Receive RF A 00TV
655 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Closed
656 11/16/2010 11:08 Receive RF A 00TV
657 11/16/2010 11:08 Receive RF 1.Front.Door - Sensor Closed
658 11/16/2010 11:08 Receive RF M MTCDDVD
659 11/16/2010 11:08 Receive RF M MTCDDVD
660 11/16/2010 11:08 Receive RF A 00TV
661 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Triggered
662 11/16/2010 11:08 Receive RF A 00TV
663 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Triggered
664 11/16/2010 11:08 Receive RF A 00TV
665 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Triggered
666 11/16/2010 11:08 Receive RF A 00TV
667 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Triggered
668 11/16/2010 11:08 Receive RF A 00TV
669 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Triggered
670 11/16/2010 11:08 Transmit E1 (1.F.Door.Module)
671 11/16/2010 11:08 Transmit E Off (1.F.Door.Module)
672 11/16/2010 11:08 Transmit F3 (L.Room.M.Phantom)
673 11/16/2010 11:08 Transmit F On (L.Room.M.Phantom)
674 11/16/2010 11:08 Receive RF A 00TV
675 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Closed
676 11/16/2010 11:08 Receive RF A 00TV
677 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Closed
678 11/16/2010 11:08 Receive RF A 00TV
679 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Closed
680 11/16/2010 11:08 Receive RF A 00TV
681 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Closed
682 11/16/2010 11:08 Macro F3 (L.Room.M.Phantom)
683 11/16/2010 11:08 Macro F Off (L.Room.M.Phantom)
684 11/16/2010 11:08 Receive RF A 00TV
685 11/16/2010 11:08 Receive RF Living.Room.Motion - Sensor Closed
-
Well so much for the "Battery Idea" though there is a correlation of some sort.
I put bad batteries in a spare sensor and triggered it now all sensors are sending strange M signals
One thing I have noticed is AHP doesn't always report the correct signals received.
Using a program created with the SDK will show the correct signals 99% of the time
and the signals are M1 SOCIALITE,01,F3,51,0E,0C-1 followed by the date/time
Note: the numbers corespond to the security sensor sending it.
So your M1 signals will vary! the last digits before the date will be a -1 or 0 indicating a open or closed state
Even Active CView available in the AHP SDK will so these
-
I beleive that this version also has bug with Dusk and Dawn timer.
None of my Timer trigger after the clock change last weekend.
Also, would anyone looking into the bug where sensor NOT triggering a macro with conditon, please? (Email using Onalert)
P.L
PL, this version still does not work on duck,dawn,day,nite. accept that. I use a switch with timer I SET to turn ON at 7am, OFF at 1800hours and have a DAY macro that just sets flag 1, a nite Macro for when this sw goes off to clear flag 1. this continues to work for day/nite/dusk/dawn triggers on all my macros.
and this version also continues to work for sending an email if macro triggers AND condition is flag 1 off. My old test macro watching same trigger with condition day and nite continue to NOT work with this version.
Please just change your dusk/dawn to a flag YOU set with a timer and your email alerts will work like mine have for years and still do with this new version.
-
I too get the crud A TV rf sent stuff. but have even in at least 3.271 too. Mine come anywhere from 0 sec to 20 minutes after a security sensor send.
-
PL, this version still does not work on duck,dawn,day,nite. accept that. I use a switch with timer I SET to turn ON at 7am, OFF at 1800hours and have a DAY macro that just sets flag 1, a nite Macro for when this sw goes off to clear flag 1. this continues to work for day/nite/dusk/dawn triggers on all my macros.
and this version also continues to work for sending an email if macro triggers AND condition is flag 1 off. My old test macro watching same trigger with condition day and nite continue to NOT work with this version.
Please just change your dusk/dawn to a flag YOU set with a timer and your email alerts will work like mine have for years and still do with this new version.
That's a really clever idea to use a flag to determine day/night status for conditions. If you can reliably use a dusk/dawn timer on a macro to set the flag, then it should be accurate across the year, too. It also saves on one of the condition slots ("Daytime" and "Nighttime" each require two condition slots - flag status only requires one).
I'm not using the e-mail send feature, so I don't need this ... yet, but I'll keep it in mind.
-
...........
That's a really clever idea to use a flag to determine day/night status for conditions. If you can reliably use a dusk/dawn timer on a macro to set the flag.....................
OOPS! since dusk/dawn/day/nite does not work for me on any of my 3 systems, and has not since like ver 3.228, it also does not work in a timer! use it in a timer and the timer wont work either! I must use my own on off times here too.
-
OOPS! since dusk/dawn/day/nite does not work for me on any of my 3 systems, and has not since like ver 3.228, it also does not work in a timer! use it in a timer and the timer wont work either! I must use my own on off times here too.
That's really strange. Have you asked X10 for help with that?
Do the dusk/dawn tables look correct (in the Hardware Configuration screen)? If not, check your location, and also the system time zone (in Windows).
Have you tried a full uninstall and reinstall of the latest version?
-
OOPS! since dusk/dawn/day/nite does not work for me on any of my 3 systems, and has not since like ver 3.228, it also does not work in a timer! use it in a timer and the timer wont work either! I must use my own on off times here too.
Me too. That's one of the reasons I stuck with 3.228 for so long, and why I haven't tried 3.296.
In my debugging, I think the problem is that your .ahx files aren't "translating" correctly between the versions. The solution is probably to delete all your existing .ahx files and start from scratch, but IMHO, that is a ridiculous solution. If there is indeed an inter-version "translating" problem, then AHP should provide a fix (a utility to read the old .ahx, fix the problem, and re-save it). But that's probably beyond any X10's programmer's ability.
-
OOPS! since dusk/dawn/day/nite does not work for me on any of my 3 systems, and has not since like ver 3.228, it also does not work in a timer! use it in a timer and the timer wont work either! I must use my own on off times here too.
Me too. That's one of the reasons I stuck with 3.228 for so long, and why I haven't tried 3.296.
In my debugging, I think the problem is that your .ahx files aren't "translating" correctly between the versions. The solution is probably to delete all your existing .ahx files and start from scratch, but IMHO, that is a ridiculous solution. If there is indeed an inter-version "translating" problem, then AHP should provide a fix (a utility to read the old .ahx, fix the problem, and re-save it). But that's probably beyond any X10's programmer's ability.
I haven't had a problem with my dusk/dawn/day/nite timers working, but maybe the dusk/dawn table is corrupted, and needs to be rewritten. One thing you might try (it can't really hurt), is to change the location in AHP to something very different, so that the entire dusk/dawn table gets re-written. Next, since you aren't using any dusk/dawn timers (nothing for the incorrect table to mess up), create a test timer, based on dusk/dawn, and see if it triggers when the new table says it should.
If that works, then you can try changing the location back to your own, and syncing again. See if the test timer runs at the correct times.
Just a suggestion - I have no idea if it will work or not.
-
cool idea. just tried it, but can.t...............
are u telling me you have TIME ZONES THAT WORK??
I haven.t had time zones that work for YEARS!
my time zone pull down has 1 choice: custom. has had this for years.
so I cannot try your idea although it sounded encouraging.....
-
Are you missing the ICities file inside the AHP folder?
-
Are you missing the ICities file inside the AHP folder?
I second that question. If you only have "custom" then it is likely your AHP is either missing the ICities.xml file, or it is corrupted.
I can send you that file if you send me your e-mail address.
--Noam
-
mine is there on this win7 64b machine, dated 5/9/2008 and is 514.420kb in size.
ok so you prompted me to replace it with one from my office machine across town - same size & date and that machine did show Dayton, OH.... but its day/nite doesnt work either for that matter.. Now I have Dayton, OH. times are the same - they did not change. it was interesting trying alaska - did u know dawn is 1900 hours and dusk is..... ready for this... 1900 hours today? cool. anyway, my switch with dawn-dusk still did not turn on - has same 7:29am 5:16pm in it on switch for dawn & dusk which is right for this time of year. let me close ahp and restart in case it only changes at those times....no change. maybe ahp only changes switch states AT THE TIME COMMANDED and so just cuz I now have dayton, oh listed, it wont change state of sw until next event. I will turn it on and wait for 5:16pm and see if it turns off. maybe this was the issue.
thanks for ideas.
-
AHP will only change the on/off state of the switch in the program if it turns the switch onor off, or if it gets commands (from a remote, or another PLC device) that turn the switch on or off.
It doesn't change based on what SHOULD be happening, if timers ran at the right times.
I hope that makes sense.
-
i missed watching dusk turn off my sw timer - closed ahp by mistake earlier.. so just made some test switches, macros with conditions it is day... tried them. still dont work. so guess it wasn't case of timezones file. sure wish i knew why some folks work and others dont...
-
I haven't had a problem with my dusk/dawn/day/nite timers working, but maybe the dusk/dawn table is corrupted, and needs to be rewritten. One thing you might try (it can't really hurt), is to change the location in AHP to something very different, so that the entire dusk/dawn table gets re-written. Next, since you aren't using any dusk/dawn timers (nothing for the incorrect table to mess up), create a test timer, based on dusk/dawn, and see if it triggers when the new table says it should.
If that works, then you can try changing the location back to your own, and syncing again. See if the test timer runs at the correct times.
Just a suggestion - I have no idea if it will work or not.
Its been a while since I went thru this, but I found invalid dates in the ahpeeprom file. Going back to 3.228 cleared them back up. Yea, if Mike C was still around, I would have emailed him the files and hope that AHP would be fixed. However, the best and easiest thing to do at the time, was return back to 3.228.
-
what gives? I just had to reboot computer for another program update and when ahp restarted, NOW my dawn/dusk condition in macro works?? I had closed and reopened it after overwriting the icities file b4.
Guess it is time to not look gift horse in the mouth and go with the flow!
Did cause a question tho: condition DAY or nite says requires "2 entries" so I added AND weekday... just removed the AND weekday and macro still works with just 1 entry "dawn." What does this mean?
-
what gives? I just had to reboot computer for another program update and when ahp restarted, NOW my dawn/dusk condition in macro works?? I had closed and reopened it after overwriting the icities file b4.
Did you kill the x10nets process before you reopened AHP?
The restart would have done this and it is my guess that is why it is now working after updating the ICities.xml file.
-
... Did cause a question tho: condition DAY or nite says requires "2 entries" so I added AND weekday... just removed the AND weekday and macro still works with just 1 entry "dawn." What does this mean?
The "Is it day?" or "is it night?" conditions MUST use two of the condition slots, because of how they REALLY work:
1. "Is it day?" really means:
a) is it AFTER Dawn?
AND
b) is it BEFORE Dusk?
2. "Is it night?" really means:
a) is it BEFORE Dawn? (between 12:00 AM and Dawn)
OR
b) is it AFTER Dusk? (between Dusk and 11:59 PM)
Since AHP uses midnight as the cutoff for each day, any conditions based on day/night must cross that threshold, so they need to use two condition slots.
For the same reason, conditions that will cross Midnight need to be split. For example, if I want a conditon based on "Between 10 PM and 2 AM", I need to write it as:
a) After 10 PM (between 10:00 PM and 11:59 PM)
OR
b) Before 2 AM (between 12:00 AM and 2:00 AM)
If you used an "AND" instead, it would never work (The two blocks of time are on opposite ends of the day)
To get around this, you can use a Dusk/Dawn timer to set a flag, and use that flag as your condition.
That would only use one condition slot ("is the flag set?").
I hope the way I explained it makes sense.
-
Did you kill the x10nets process before you reopened AHP?
The restart would have done this and it is my guess that is why it is now working after updating the ICities.xml file.
ah, prob right. altho thought I read ver 3.296 finally kills x10nets when program quits now. tnx
-
I'm running version 3.299 (plug-ins) and x10Nets is still running when I exit AHP. This was probably the case.
If it's working though, that's a plus. >!
-
... altho thought I read ver 3.296 finally kills x10nets when program quits now. tnx
If they killed the x10nets service, then none of the SDK-created programs (or even the manual control using ahcmd) would work. Those all require the service to be running.
-
OK Noam, now I'm still being dense I am sure... I of course understand how making DAY or its NITE would work behind the scenes on a 12 hour clock (vs not needing 2 tests for 24 hour clock) but I am not programming the ahp internal software so I really don't care how many checks they need to do to make it work. to use it I simply drag "DAYTIME" to my condition block to use it. I don't drag two things, just one thing. So why does it say it requires 2 things? that is my question.
-
OK Noam, now I'm still being dense I am sure... I of course understand how making DAY or its NITE would work behind the scenes on a 12 hour clock (vs not needing 2 tests for 24 hour clock) but I am not programming the ahp internal software so I really don't care how many checks they need to do to make it work. to use it I simply drag "DAYTIME" to my condition block to use it. I don't drag two things, just one thing. So why does it say it requires 2 things? that is my question.
Yes, YOU only drag one block over. However, that one block takes up two spots.
And you would still need the two tests for a 24-hour clock, too. The CM15A, and most electronic devices, use an internal 24-hour clock.
If "Day" meant the time from 12:00 AM until 11:59 AM, and "Night" meant the time from 12:00 PM until 11:59 PM, then you could use only one condition (is it AM or PM). However, since "Day" means "after Dawn and before Dusk," and "Night" means "before Dawn or after Dusk", it still requires two conditions.
Once again, using a timed macro to set a flag would allow you to use that flag as your one-and-only condition for day/night macros.
-
Noam, I gotta respectfully disagree with your reasoning why DAYTIME condition says "requires 2 entries." How they program a condition internally is none of the users business or concern. I just thought of why I believe they wrote that on the condition: it is a typo by the programmer! It should not be there! Here's why I say this...
Looking at condition DATE RANGE, it says "requires two entries." And it does! The user has to enter two entries - the start and the end dates. Ditto for conditions holiday & time range. But for daytime and nighttime conditions, the program automatically puts in & uses the two entries - dawn & dusk! Now if there was an edit button on these 2 conditions that allowed us to change the 'timer' from dawn/dusk to TWO ENTRY times of our choice, then yes, that note would be correct on the conditions. But no edit button, so no two entries required!
Hence it is a programming typo no one ever told them about, so they have not yet fixed it! Hopefully the new programmers see this for next version....
-
Noam, I gotta respectfully disagree with your reasoning why DAYTIME condition says "requires 2 entries." How they program a condition internally is none of the users business or concern. I just thought of why I believe they wrote that on the condition: it is a typo by the programmer! It should not be there! Here's why I say this...
Looking at condition DATE RANGE, it says "requires two entries." And it does! The user has to enter two entries - the start and the end dates. Ditto for conditions holiday & time range. But for daytime and nighttime conditions, the program automatically puts in & uses the two entries - dawn & dusk! Now if there was an edit button on these 2 conditions that allowed us to change the 'timer' from dawn/dusk to TWO ENTRY times of our choice, then yes, that note would be correct on the conditions. But no edit button, so no two entries required!
Hence it is a programming typo no one ever told them about, so they have not yet fixed it! Hopefully the new programmers see this for next version....
Mike - That's a very creative explanation. I'm not saying it is wrong, but it isn't the answer I was given by X10.
I asked the developers about this when I was beta-testing the SmartMacros add-in before they released it back in 2004.
"Entries" refers to the condition slots in the top portion of the macro, not the dates or times you enter into the condition itself.
Each macro can have up to three condition "entries." Using one of the "time range" or "date range" conditions uses up two of those slots (entries), because one is used for the "after" time at the beginning of the range, and the other for the "before" time at the end of the range.
"Daytime" and "Nighttime" are really the same as using the "Time Range" condition. It uses up two of the slots, or entries, in the conditional part of the macro.
You can try it yourself. Put in two conditions (for example, a "flag status", and a "day of the week"), and THEN try to add "daytime" or "nighttime". It won't let you.
I think you're right that the wording could be better. Perhaps the word "slots" would have been a better choice.
-
Ya, maybe it should say USES two entries huh?
OK, you win :)