Print

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

[JeffVolp]

The XTB-IIR sends "P16 Status ON" at power-up, but that should not effect any module.

Jeff

[Noam]

The XTB-IIR sends "P16 Status ON" at power-up, but that should not effect any module.

Jeff

Jeff -
If only I could use that to trigger my "power restoration" macro... ;-)
Does it do it EVERY time it powers up, even if the power was only out for a brief moment?

Perhaps it's something to think about for a future revision of the firmware - an optional HC/UC to send a command on when the unit powers up, or perhaps a few seconds later, that can be used to trigger macros and such.

[JeffVolp]

The XTB-IIR sends "P16 Status ON" at power-up, but that should not effect any module.

Does it do it EVERY time it powers up, even if the power was only out for a brief moment?

No, there is a lot of energy storage in the XTB-IIR to deliver the high power signal bursts, so it can take up to 10 seconds for that to discharge when power is removed.  A short dropout lasting a second or two would not be recognized.

Jeff

[Noam]

The XTB-IIR sends "P16 Status ON" at power-up, but that should not effect any module.

Does it do it EVERY time it powers up, even if the power was only out for a brief moment?

No, there is a lot of energy storage in the XTB-IIR to deliver the high power signal bursts, so it can take up to 10 seconds for that to discharge when power is removed.  A short dropout lasting a second or two would not be recognized.

Jeff

Aww. That's too bad.
Maybe you can look into that for the next version of the hardware (XTB-3R?)

[Noam]

OK I did a few tests with my modified CM15A.
Where I added a switch to switch the RF receiver in the CM15A Off; with the receiver ICs disable signal pin.
Cleared the Activity Monitor Screen.
Verified an RF remote was not being received or processed at all.
Close AHP.
Start AHP. Activity Monitor still clear.
Close AHP. Unplug the USB Connector for the CM15A. Reconnect the USB Connector for the CM15A. Restart AHP. Activity Monitor now shows two entries. Receive RF A Unknown. Yes the receiver in the CM15A is still disabled.
Clear Activity monitor and close AHP. Turn OFF X10nets.exe. Unplug and plug in the CM15A a few times. Activity Monitor shows no Received RF A Unknown entries. 

Changed Monitored House Code but the Received RF A Unknown was the one still the reported message.

I wounder since the CM19A was added to AHP as a controller. If connecting and disconnecting the USB cable with X10nets.exe running triggers something? I have not tried anything with a power saving mode where maybe a USB port is turned on and off.

Brian -
Thanks for doing the research. I recall something from years ago (I'd have to use the "less-than-excellent" search tool here to try and find it) where a user reported all of the "status" commands that the CM15A sends when booting up, connecting to the PC, etc.
I haven't really paid attention to the Activity Monitor is a while, so I don't know if the "RF" commands I'm seeing are really from the CM15A or not.
They clearly aren't REAL RF commands, or my other CM15A would have seen them (AND your "deaf" CM15A wouldn't).
I think this is similar to the "P16 On" that we used to see at power-up, which was never usable to trigger anything from what I recall.

I noticed something VERY strange, when I was trying to figure out one of my other problems (All of my flags suddenly got flipped to "on" last Friday evening, with no indication as to how - not the first time this has happened).
I noticed that I see a pair of "Receive RF A Unknown" at the same exact time that I see the "Multimedia Class Scheduler Service" start (in the Windows system log). I am running Windows 7 pro 64-bit.
I don't know which is the cause and which is the effect, but I think the "Receive RF A Unknown" causes the service to start, because stopping and restarting the service DIDN'T cause the "Receive RF A Unknown" to show up, and I stopped the service for several hours, during which I still saw the "Receive RF A Unknown" show up at least once in the middle.

I just ran an experiment:

I opened AHP, and verified that the last command in the log was a normal one (turning off my humidifiers).
I then closed AHP.
I then opened the Device Manager, and disabled the hub that the CM15A is connected to.
I re-opened AHP, and the log now shows a SINGLE "Receive RF A Unknown" command.
I closed AHP, and opened the Windows System log, and I see the "The Multimedia Class Scheduler service entered the running state" event.
I then re-enabled the USB hub.
I re-opened AHP, and looked in the log.
I now see a second "Receive RF A Unknown" in there, at the time I turned the hub back on.

I certainly see a correlation between those commands and the USB being connected/disconnected.
However, I'm wondering how that relates to the "Multimedia Class Scheduler" service in Windows, and why my system seems to be dropping and reconnecting that device periodically.

Any ideas on this one?

[ErikP]

I think my PC was putting the USB ports to sleep to save power, so waking them up caused the CM15A to be rediscovered, and it interprets that as the "Receive RF A Unknown", or something like that.

I wounder since the CM19A was added to AHP as a controller. If connecting and disconnecting the USB cable with X10nets.exe running triggers something? I have not tried anything with a power saving mode where maybe a USB port is turned on and off.

In short...  yes.
This being caused by the RF Transceiver Init command.  When CM19 support was added it caused this message to appear in the history logs.  It was never intended to show up in the Activity Monitor so it didn't know how to parse it, and anything it can't parse it displays as unknown.  It is now properly filtered out with build 296, but there is some discussion on whether it should be or not (http://forums.x10.com/index.php?topic=21738.msg122948#msg122948)

00TV is a similar message which started to bubble up recently which shouldn't, and it also has been filtered out correctly now in 296.  This is a blank command (all 0 values) which is sometimes used as part of another command, but by itself means nothing.

M Unknown or more recently seen as M MTCDDVD is a bug in security command parsing in the Activity Monitor.  Please refer to this thread for more information about M MTCDDVD
http://forums.x10.com/index.php?topic=21743.msg122947#msg122947

[Noam]

In short...  yes.
This being caused by the RF Transceiver Init command.  When CM19 support was added it caused this message to appear in the history logs.  It was never intended to show up in the Activity Monitor so it didn't know how to parse it, and anything it can't parse it displays as unknown.  It is now properly filtered out with build 296, but there is some discussion on whether it should be or not (http://forums.x10.com/index.php?topic=21738.msg122948#msg122948)

Erik -
Please see my response in the thread you mentioned (http://forums.x10.com/index.php?topic=21738.msg122948#msg122948), regarding the "Receive RF A Unknown" commands.
My system seems to be affected more than I think it should be, and commands are being dropped during the handshaking.

[IPS]

Where can I get 3.296 ?
Thanks

[Noam]

Where can I get 3.296 ?
Thanks

Here: http://www.x10.com/support/support_soft1.htm

[Noam]

I wanted to provide an update for anyone following this thread, and ask if anyone else has seen anything similar.
After working with the X10 developers for the past two weeks, it looks like the USB stack on my Windows 7 Pro 64-bit PC is re-initializing several times a day. The strange thing is, it only seems to affect the CM15A. Other USB devices (such as the other hubs and my UPS) don't seem to re-initialize.

I can't prove, one way or another, if my USB extender is at fault or not. I thought I observed the same issue when I was running without the extender, but I can't be 100% sure. I have ordered a different extender (one that was reported to work well here on the forums), and I should have that in a few days.

When this re-init happens, which takes two or three seconds, any X10 timers still seem to run (a second PC I have with a second CM15A is watching the powerline). However, those commands are not logged in the AHP log. I have been told that the CM15A is *SUPPOSED* to log events while it is disconnected, and update AHP when it reconnects, but that isn't happening in this case.
This has been happening most often to me in the morning, when I have three lights set to turn off with a dawn delay (30 minutes after dawn). All three lights turn off, but only the first two are logged in the AHP activity log. The third one is skipped, because there is another "Receive RF A Unknown" message, indicating a re-init sequence took place.

Now this isn't the only time I see it happen. It happens sometimes immediately after I manually turn on one of my Smarthome two-way switches (I see it receive the command, and the re-init), and it also happens completely at random sometimes, too (when there is no X10 activity going on).

In the meantime, the most recent version of AHP (3.296) is filtering the "Receive RF A Unknown" messages from the log within AHP. However, if you save the log out to an HTML file, they are still there.

Is anyone else out there having issues where timers are running, but some commands are not being logged?
If so, have you tried saving out the AHP log and checking the file for that time when those timers ran?

Please let me know, as I'm trying to gather as much information for the X10 developers to investigate this issue, and find a proper resolution.

Thanks.
--Noam

[IPS]

Thanks Noam Now am running 3.296 on with XP. For the last 30 min, I have not given any commands nor are any timers on but this is what the activity monitor has lodged:

11/20/2010 10:13:50 AM received RF  M MTCDDVD
Repeat
11/20/2010  10:18:59 AM Received RF M MTCDDVD
11/20/2010  10:18:59 AM   _DO_
-DO_
-Do_
-DO-
11/20/2010  10:19:00 AM  -Do-
                  10:29:38 AM  -Do-
                   10:29:38 AM Received RF Basement-Grage Door - Sensor Closed
And repeats in various sequences

Sun or wind triggered sensor 14A so some Macros were triggered

That's about all for today.
Noam I don't know if that will help you with data collection.

IPS

[mike]

........ using the cm15 with a v572 .........
I looked in the log of iHouse and blasting away was "a" command.
.................I couldn't figure it out so I reprogrammed the v572 to disable the "a" house code.  Hooked everything back up and got my system working again.

So in the long run I really still don't know what caused the "a" flooding. 

to ease ur mind I will tell u what caused your a flood:  the V572:  Warren had a bug in one of his firmwares about 1.5yrs ago that I had so corresponded with him;  I returned my 2 v572s for fw update and that fixed it. 

[mike]

Sounds like you need to politely ask neighbors (especially those whose electricity comes from the same transformer as your house) if they have X10......I've had x10 since the middle 1980's and NOBODY else on my transformer has X10 in any form.

fyi, with my XTB-IIR I can sometimes turn on lites in my 'neighbors' house.  we live 1/2 mile off the road so have 7200v line to our xfmr by the house.  when neighbor house went in years later, we allowed power company to tie into our 7200v line 1/4 from street to power their xfmr.  OK, they were crazy people whoshot anything that moved, including our pets so we made them move by buying their house.  since it was empty for a long time I put x10 motion sensors & lites in, a radio that would go off and we would hear via vox on little 2 way radios at our house.  anyway, we taught the other neighbors that if the 4' floresecent lite in the front window when on in the middle of the nite, there was motion on the backdoor porch....  sometimes it would be animals and sometimes we got a few calls......being lazy, I learned to send A2 OFF from a remote at my house and if I held button down for about 10 seconds, the lite & radio would go off.  consistently.  I could have neighbors on phone and say 'watch this' and turn that lite on and off from y house.  thru 2 pole round transformers!  took a couple dozen sends (10-20 sec on the button) but it worked 90% of the time. 

Moral of this story is perhaps you might have to go past looking at your possible neighbor on same xfmr secondary.  especially since this is not a lot of code received and some are .unknown. like they are semi corrupt.

[mike]

...................
When my DS10's do fire either Motion detected, or Reset, I get upwards of 10 of each received by my CM15, each one follower by a Received RF M Unknown and/or a Received RF A 00TV..........
Like I said, I'll try re-installing everything DS7000 and AHP this weekend - my gut is telling me it has something to do with the new OnAlert/OnAlertMobile.

One last thing - I was sure I installed 3.285 on the 2nd, but the ABOUTs show 3.286 installed on the 4th??? for all modules??

Arrrrgh.

I too get the 00tv and m unknown. I figured it is firmware bug in ahp and ignore it.

I think addins did not get automatic update until 3.296....  so unless u put it in you have to update add ins individually.

[mike]

thanks.
Since I don't have any of the security components, nor do I have any motion sensors, can someone tell me if either one can be set to send a "All Lights On", followed by an "All Units Off" about a minute later?

Short of that, could a remote  with dying batteries (or with something on top of it) do the same thing?

Thanks.
--Noam

i am going down this thread fro the top so hope I am not repeating anything others have already said further down.....

yes, ds7000 sends all lites on/all lites off - on its house code 1x per sec or so when triggers.  that what you mean?

I was going to ask if you ever looked at what house code your security devices are on?  it doesnt matter to the ds7000 as it uses the 32bit data instead, but I recall years ago you can edit a sec device, change it to a non sec device to see what house code it is on, change it if u want, then change it back to the sec code.  that said, could your random stuff be sec devices on B house code that normally means nothing, but what if they send their normal 60 min on/off report in at same time as something else sends so they clash;  perhaps the 32bit sig gets gobbled up and its 16bit house code goes thru instead?