No announcement yet.

CM15a: X10 devices keep switching to "OFF"

  • Filter
  • Time
  • Show
Clear All
new posts

    CM15a: X10 devices keep switching to "OFF"

    Using CM15A / HS .94 on Win 8.1
    • All x10 devices switched to status "OFF" seemingly at random, after a few minutes to at most 2 hours with nothing showing in the log
    • Curiously the devices didn't actually switch to "OFF", it was only the device status that changed
    • I (finally) switched to "developer" mode and found the switching occurred simultaneously with a log recording:
    • CM15A DEBUG Received CM15 Address:M1, Command:socialite,7e,7b,f2,71,84
    • I have no device with address M1, and I don't know what the "command socialite " means

    Suggestions anyone?

    It's most likely noise on the powerline. Random noise can wreak havoc on an X10 installation.


      Tnx Rupp for your prompt reply, but in my opinion unlikely to be noise, same X10 setup works perfectly with HS3/CM11A, and same CM15A interface has worked perfectly for many years on HS2 (and still does so at this moment).
      In fact I can run both HS3/CM11 and HS2/CM15 perfectly on an old Win7 computer but my real problem is that I want to move my setup to a new WIN 8.1 computer and Win 8 doesn't have a CM11 driver, so HS3/CM15 is my only option
      BTW, wouldn't noise actually also switch the devices, and not only change the status in the software? And why only switch to "OFF" and never to "ON"? This must be some bug hiding in the code.
      Last edited by WfromL; October 17, 2014, 10:17 AM.


        Originally posted by WfromL View Post
        CM15A DEBUG Received CM15 Address:M1,Command:socialite,7e,7b,f2,71,84
        Out of interest I looked back through my log, with filtering set to only show CM15 commands, and I have a similar pair of commands received about 2 weeks ago.
        Oct-05 23:29:38 CM15A DEBUG Received CM15 Address:M1, Command:socialite,d6,7b,ed,65,80
        Oct-05 23:29:38 CM15A DEBUG Received CM15 Address:M1, Command:socialite,d6,7b,ed,65,80

        I also don't have any devices on M1. I don't think it caused me any issues, although I probably wouldn't have noticed my X10 devices going to off at 11:30 on a Sunday night.

        I have also in the past received some strange commands on A6, which I again don't have any devices set to:

        Oct-10 08:23:48 CM15A DEBUG Received CM15 Address:A6, Command:devicestart
        Oct-10 08:22:21 CM15A DEBUG Received CM15 Address:A6, Command:devicestop

        I think these caused a device on O6 to turn Off which had me baffled at the time. I put this down to a glitch in my CM15 hardware as unplugging and plugging it back in whilst HS3 was shut down appeared to cure the issue, at least for a while.

        Maybe these are coming from the plugin after all.



          Tnx for looking at this Steve!
          In fact I think this can easily go unnoticed. I only found out because I have an event that switches on my bathroom heating based on the status of a virtual X10 device. That device has to be "ON", but as the staus always changes to "OFF" I woke up with a cold bathroom and that's why I noticed.


            The M code for X10 is 0 0 0 0 which is the most likely house code to be tripped by power line noise. HS should have received an M1 on or M1 off if a device was sending the code. If HS registers a M on or M Off this is again a very good indication that it's noise and not a device as the device would have sent the associated on, off, dim, etc along with the command.


              OK Rupp, I appreciate your comments, but allow me to summarize my findings as follows:
              • I triple checked I don't have a device sending M1
              • I'm far away from neighbours, and I never saw any X10 signal that was not generated by my own devices
              • Using other X10 receivers ( Marmitek, ActiVHome, RFXCOM ) I never see an M1 command,
              • so yes, it is definitely not a device sending M1 ON/OFF.
              • This is also confirmed by the fact that the X10 commands OFF are NOT executed by any devices, it is only the STATUS that changes in the HS3 software.

              But is it noise? If so I still think there is something wrong with the CM15A plug in because
              • the CM15A hardware has 99% reliability with HS2.
              • HS3/CM11A is also 99% reliable
              • HS3/CM15A fails with 100% certainty within less than 2 hours, so it is effectively unusable

              My HS3 setup is essentially identical to my HS2 setup: same devices, same events, same plug ins (RFXCOM and CM15).
              If it is indeed noise, that means the HS3/CM15A plug in software is much more sensitive softwareto noise than it should be. Is this even possible?
              Last edited by WfromL; October 17, 2014, 02:11 PM.


                Here I utilize CM11A's, TW-523's, WGL 800's and Jeff Volp's X-10 booster and dual phased TW-523 controller and booster. (along with Zigbee, Z-Wave, Insteon and UPB).

                Jeff Volp's stuff is X-10 on steroids.

                I have seen stray unexplainable poltergeist X-10 stuff.

                Fer sure my playing around with the TED energy module caused a bunch of noise.

                I do have a rack full of UPS's sitting next to the rack with the HS stuff and next to the controllers plugged into autonmous circuits today. The UPS's are work fine with X10 and not signal sucking that I can tell; well everything still works fine.

                There was a time where I used the X-10 from the Insteon module (using both in Homeseer).

                There too just watching the Insteon X-10 stuff on Homeseer I would get unexplicable X-10 signals. Not sure if I was seeing them or the source was the Insteon X-10.

                I know when I removed the X-10 part of the Insteon PLM the extraneous signals went away.

                The above said it doesn't explain why you didn't see this with Homeseer 2 but now seeing it with Homeseer 3.

                You can if you want monitor your X-10 signals with the signal monitor (think I lost mine) watching your stuff with or without the CM15A plugged in. You can also monitor the serial port by mirroring the serial communications between Homeseer 3 and the CM15A using that free Microsoft serial port mirror monitoring program.

                The HS2 X10 CM11 Plugin while working does show communications errors still today.

                You can also use the WGL-W800 or the RFXCom stuff. I do not have issues today with the serially connected WGL-W800.

                HS3/CM15A fails with 100% certainty within less than 2 hours, so it is effectively unusable
                Monitor the console logging stuff and do a port mirror of the traffic between HS3 and the controller; you might see something there.

                I do not have a CM15A though to test here.

                A new Homeseer 3 lite RPi user is today testing his CM15A (tarbat- Christopher) with the Linux version of Homeseer 3 lite and I think that its been working fine for him. (sort of) See here:


                Just guessing here....

                BTW I have fond memories of working in Brussels, Belgium many years ago. Neato country you live in.
                Last edited by Pete; October 17, 2014, 04:01 PM.
                - Pete

                Auto mator
                Homeseer 3 Pro - (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb- Mono 6.12.X - HSTouch on Intel tabletop tablets
                Homeseer Zee2 (Lite) - (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.12.X
                HS4 Pro - V4.1.11.0 - Ubuntu 20.01/VB W7e 64 bit Intel Kaby Lake CPU - 32Gb - Mono
                HS4 Lite -

                X10, UPB, Zigbee, ZWave and Wifi MQTT automation-Tasmota-Espurna. OmniPro 2, Russound zoned audio, Smartthings hub, Hubitat Hub, and Home Assistant


                  Yes, I'm using a CM15PRO with HS3-Pi without any problems. I've checked the log, and don't see any extraneous X10 messages that shouldn't be there. Although I do see several Z-Wave messages that shouldn't be there from devices not present on my setup!

                  Note that the CM15A plugin in HS3-Pi is v3.0.0.4.


                    Originally posted by WfromL View Post
                    HS3/CM15A fails with 100% certainty within less than 2 hours, so it is effectively unusable
                    My experience is certainly different to yours. I have been running the CM15 plugin on HS3 windows since it was released and it has been running for some considerable period of time now with little problem. There were some issues with the first couple of betas. However, apart from the pretty rare strange log entry for a received command noted higher in this thread, it is as solid as it was on HS2 for me. I realise that's not much help to you.
                    I'm currently on
                    I have a mixed X10 and ZWave setup and all new devices I install are ZWave. I suspect I am continually increasing the noise levels on my wiring as I add more and more little USB power supplies around the house for ZWave sensors of one sort or another. I'm sure my X10 setup which has been 99% reliable for years will eventually drown.

                    I'm generally finding HS3 pretty solid these days and I have come to like it more and more. My HS2 was rock solid and the migration to HS3 through various betas has been painful but I have come to appreciate the redesign, even CAPI.



                      Tnx for all feedback!
                      Steve: good to hear your CM15 works reliably, so it must be something wrong with my setup, I'll continue experimenting
                      Pete: I'm monitoring ports now, so far nothing significant showing


                        Tracked down the culprit!

                        I finally found the culprit, and it's not noise.
                        I searched in vain for a source of noise, unplugged the whole house until I ended up with just my computer and the CM15A interface: the problem remained just the same. With nothing else connected to the power line I realized the rogue signal must be X10-RF. I then noticed the switching of all X15 device status to off occurred with 2 periodicities: 84 and 78 minutes, seemed like a "keep alive" signal. I then looked at X15 with my old ActivHome software, and sure enough: there was a "Receive RF M MTCDDVD" message coinciding with my problem, 100% reproducible. To find which device did it I used the RFXCOM RFReceiver: that gave me finally the culprit: a Marmitek DS90 door sensor (the only RF X10 device I have). Taking the batteries out and the problem (almost: see the bad news at the end of this message) disappeared. A Google search for MCTDDVD wasn't very conclusive: as I understand it, it is either a bug or a legitimate (but undocumented?) X15 RF code, but nobody seems to know what that code means.
                        Now the bad news: I can also produce the M MTCDDVD code with my SOMFY RTS remote but in this case it is only 80% reproducible. Really strange behaviour: Somfy is not an X10 RF signal so why is it registered as such by HS3, and why only 8 out of 10 occurrences? I can replace the DS10 door sensor with a Visonic, which gives no problems, but I cannot change my Somfy blinds motors. So my problem isn't solved.
                        Anyway, I consider this to be a bug in the HS3/CM15A plugin. The HS2/CM15A combination doesn't register this weird MCTDDVD code, so it should be possible to ignore it with HS3 too.
                        It would help if there was a possibility for CM15A to "ignore" a specific houscode, such as is the case with the ACT TI103 X10 interface.
                        Last edited by WfromL; October 24, 2014, 05:15 AM.


                          Just to make sure I hadn't a defective DS90 I borrowed two more Marmitek DS90's from friends.
                          Exactly the same problem: The keep alive is interpreted by CM15a plug in as
                          MTCDDVD. I noticed that opening the case, thereby triggering the tamper switch, also generates this code, but normal operation (door open or closed) does not.
                          Again, the RFXCOM receiver interprets these RF signals correctly.


                            No problem with HS3 on Linux!

                            I updated to HS3 .143 on UBUNTU. This version finally works with CM15A, and all X15 events work perfectly. No problem with the infamous M MTCDDVD code.
                            Have been running for over 24 hours now without any problem.
                            The HS3 linux has as latest X15 plug in, so I tried to copy the old versions of Windows to a HS3/Win .143 installation, but no luck: the bug is definitely there in HS3 Windows!
                            Last edited by WfromL; November 29, 2014, 11:22 AM.


                              Nobody else has this problem?

                              CM15A on HS3/Windows is still unusable for me.
                              Anybody else using a DS90 or a Somfy remote? The RF signal of both these devices trigger the CM15A devices status (reliably!!!, not noise!!!) to "OFF" (but they don't actually switch the devices).
                              Same CM15A on HS3/Linux or HS2/Windows works perfectly, so the CM15a is not defective.