CM19a issue

[alzzy]

I am using cm19a in HG on the Pix10hub 1.1 release. Running on Pi Zero W.

I have my cm15a unplugged (also its RF interface is disabled). I have shutdown my Alex10 app and its HA bridge. I have no other x10 software running and the cm19a is my only x10 interface. I use at v572a tranceiver. I have cm19a selected as the x10 interface in HG. Interface function is erratic. If a command is not sent to cm19a for several seconds, it takes two clicks of an x10 module On or Off button in HG for the cm19a to transmit the command. Its like the first click wakes it up and the second transmits the command. I have tried 2 different cm19a's with the same results. Note: my RF connection and v572 transceiver response is very reliable as I have very excellent results with cm19a controlling my devices when running it with Alex10. The other thing I noticed is that it appears the flash of the led on the CM19a when sending a command is shorter in duration when using HG than when using Alex10 if that means anything.

Any help is appreciated!

[mralapete]

CM19 driver working in HG v1.2-Stable .28 perfectly both on the Raspberry Pi Zero W and the Raspberry Pi 3+ under Raspbian Stretch Lite. Also working perfectly in Ubuntu 18.04. All commands issued are acted upon instantaneously.

Suggest you look at the additional software you are running in parallel with HG to isolate you problem. You may need to run that additional software on a separate Pi server as the additional overhead on the Pi Zero W may be causing a bottleneck. Alternatively a change to the Raspberry Pi 3+ may be the answer.

You could of course run one of the many Linux resource monitors available to track your Pi performance.

[tuicemen]

My Cm19a led doesn't even light up the slightest using HG I actually Had thought the LED had burnt out. I use the cm15 but have tested the cm19. I too have experienced the need for a double push of the on or off buttons in HG occasionally if the system has been idle for a while. I'll do a bit more testing to see if it is a particular module which may indicate a noise or signal sucker at play here. I'm not sure as yet if this affects macros or timers here.

[alzzy]

Tuicemen, How could it be a module problem if the CM19a doesn't light up? The cm19 isn't transmitting a command, Doesn't it have to be a Pi or HG issue or HG driver issue?

[mralapete]

Guys it's not a HG issue at play here as I've stated above. Your problem lies elsewhere.

[tuicemen]

My Cm19 (unit)LED light has never lite up using HG (that I noticed) but the commands do go threw and modules do come on/off. RF signals can be affected by a number of things in fact nothing is received if my CM19 is in the basement. @mralapete I tend to agree however I never ran the CM19 for an extended time with a large configuration. I believe location of the cm19 to be the major issue at play here. @alzzy is the CM19 in the same location as it was running the other software? If not try placing it there.

[alzzy]

My cm19 is in the same position it was in with Alex10. Its not a position or RF issue. I have rock solid RF in my set up. In my set up when the cm19 led does not light up I get no module response , when it does I get module response. Every time. Its either a driver issue or the Pi zero has an issue.

[mralapete]

The Pi Zero W is a relatively low speced board to run two separate servers on. The overhead placed on it from additional traffic could well be causing your problem. The Pi 3+ would be a more suitable unit to use here or as I suggested split the load between two separate Pi servers and expose one server to the other via the many methods explained in the HG documentation.

Once again the CM19 is functioning normally.

[alzzy]

Well that's a bummer! Tuicemen do you agree?

[alzzy]

The little cm19a is overburdening the Pi Zero?? But the cm15a doesn't?

[tuicemen]

The cm15 is self powered the cm19 draws power from the Pi The Zero may not be supplying enough power to give a good RF signal. As I stated before I've not done enough testing with the CM19 and the Pi Zero I only know HG does send the RF signal to the CM15 & 19. I only have Pi zero W boards here in the city.

[genemars]

When the RF signal is weak, sending the same message more than just once can improve the result (maybe the initial RF start burst is not recognized very well). Even X10 sensors send 4 times the same message (with a very short pause between each), to give the message more chances to be received correctly. So I can make CM19Lib send the RF message twice by default and make this parameter configurable somehow. Any thoughts?

[alzzy]

genemars: Sounds like the thing to do! But I'd vote for Thrice just to be sure.

[tuicemen]

@genemars sending the RF signal twice by default would improve reliability for sure At least for the ON/Off However this would affect dim functions I suspect unless you coded the CM19Lib different for dim sends.

[alzzy]

genemars: is sending a command and triggering a cm19a a significant increase in load on the pi processor over doing the same with a cm15a?

[tuicemen]

@alzzy I'm not sure how close your pi/cm19 combo is to your v572a but why not put them next to each other as a test. I know if I put my cm19 next to a transceiver it works every time the further away the more unreliable it is. Also I've now tested the CM19 with 3 different Pi Zero W boards. Some actually light up the LED on the CM19 with a command send. So they definitely don't all send the same power to the CM19 which may explain why some users have such a reliable setup. One of my Pi ZeroW boards requires a double mouse click of any button in HG, others work with one mouse click this is with the CM19 never changing location. All boards were using the same Power supply so in my case one ZeroW boards quality is not up to pare.

[alzzy]

Maybe the PI Z usb port can't reliably supply power to the cm19 and the thing to try is to provide power to the cm19 directly from a power adapter rather than have the Pi Z supply power thru the usb port. Thoughts? Do you know if anyone has had success with a powered usb hub on a Pi Z Pix10hub?

[tuicemen]

A powered USB hub would most likely help although some users have fried their zero W boards with a powered hub. For this reason I won't recommend you try it. If you do attempt this you have been warned should you fry the board.

[mralapete]

@genemars what work have you based your CM19 driver on. There's one recent user of HG that is experiencing difficulty using your CM19 driver and there's a third party server in the form of HA Bridge involved in their setup. Maybe if you installed the HA Bridge yourself and tested your driver you could determine if the problem lay with your CM19 driver and not with how comms are handled between the HA Bridge and HG before you start making changes to your code.

Personally I'm experiencing no issues with the CM19 driver. From what I can gather the OP is trying to establish an Alexa setup here on a Raspberry Pi Zero W using the 3rd party HA Bridge and HG. If its such a popular request maybe you could do away with the need for the 3rd party HA Bridge and integrate Alexa support directly in HG as was being worked on by a number of the more experienced HG users/contributors before development halted. This would give greater appeal to the more popular technologies like ZWave etc

[tuicemen]

I don't believe the third party application (HA-Bridge) is the issue users have been using this bridge for several years now. It just sends a call to direct to the API. However the Hue Bridge in HG just needs some simple code adjustments for users that have a Password enabled in HA-Bridge other then that the connection is the same. After several tests with different PI Zero W boards my conclusion is the Pi Zero W is the weak link, and no software is to blame. North American users have always complained about RF range here. I tested this with just HG installed and no Bridge I have range send issues with the CM19 on a Zero W

[alzzy]

I am confused by the above. Tuicemen, what is your sense of the Zero W issue. USB power to power the cm19a or processing power to command it? If is usb power then perhaps an external supply to power the cm19a could fix it.

[mralapete]

Ok. I'll leave it to the X10 North American v European debate so. I don't believe that this is an issue though. What I will say is that any additional overhead on a lower speced board like the Pi Zero W v the Pi 3B+ will introduce performance issues. Fact. I've tried the HA Bridge on the same Pi Zero board as HG and on a separate Pi Zero board and there is a minor difference.

Once the correct power supply is used on the Pi Zero W power output to the CM19 will not be an issue so that is not your problem.

As you can imagine the X10 user base on HG would be quite small so I wouldn't hold out on too many other replies on this issue. Maybe you guys could work this out between the two of you.

[genemars]

@genemars [...] maybe you could do away with the need for the 3rd party HA Bridge and integrate Alexa support directly in HG as was being worked on by a number of the more experienced HG users/contributors before development halted. This would give greater appeal to the more popular technologies like ZWave etc

Yes I might add support for Alexa and other voice controlled gateways directly in HG. But I'm currently working on something else, so not sure when I'll start looking at this.

[genemars]

@tuicemen @alzzy even though probably this is not an issue I wanted to make a small modification to CM19Lib and XTenLib to make RF comms more reliable. I'm publishing the new release shortly.

[tuicemen]

@alzzy In my opinion I wouldn't and don't intend on using a CM19 with my Zero W board. If you want more reliable performance use a CM15. I plan to test a CM19 with my pi 3B+ which is at my off grid place but that will not be for several months. @genemars I'm sure the small modification will be most welcome. while playing with the CM19 I noticed if I had HG set to use the CM15 it would still see RF the Cm19 received so I wonder if the two (CM19Lib and XTenLib) could some how be combined.

[genemars]

I wonder if the two (CM19Lib and XTenLib) could some how be combined.

Yes it can be done but I don't see any possible use.

[tuicemen]

Yes it can be done but I don't see any possible use.

Other them a smaller download I don't see any benefit except maybe adding a option for a cm15 to send either RF or PLC with a simple switch option in the widget instead of having to create a macro.

However this was just me thinking out loud ;)

[alzzy]

genemars: thanks for the effort! Looking forward to that release.

[alzzy]

I never had reliable rf coms with the cm15. If it were me I would disable the cm15 RF capability and install a V572A transciever. did it 20 years ago and have had great rf coms ever since.

[tuicemen]

I never had reliable rf coms with the cm15. If it were me I would disable the cm15 RF capability and install a V572A transciever. did it 20 years ago and have had great rf coms ever since.

Yes I'm one of the few that have reliable RF with my CM15A. However I rarely send any RF from my CM15A. HG by default sends PLC from it which is why for most people the CM15 is the better option over a CM19

I do believe @genemars new update to the drivers will no doubt improve things for you.

[tuicemen]

I'm wondering if we got off track from the OP, possibly due to the title. The issue was the Web UI failed to send a command on first click of a device if no activity on the web page for some time. This morning I came in started the PC then opened the HG Web UI Running on my Pi and clicked on the widget for my office light. Nothing happened and this Pi is connected to a Cm15. a second press of the mouse turned on the light. Usually I double click on things in the computer so this may be why I never noticed this prior. I don't believe this is related to drivers for either the cm15 or cm19 but more the Web UI as all my automation ran successfully during the night.

[alzzy]

Or there could be 2 issues!

[alzzy]

As I have HG running on win10 PC with stable.28 and with cm19a i don't have the double click issue.

[tuicemen]

I don't believe there is/was a driver issue as I stated my issues with the CM19 are range. What I experienced this morning was what you first raised in your OP only difference being the controller.

[tuicemen]

As I have HG running on win10 PC with stable.28 and with cm19a i don't have the double click issue.

So this proves it isn't a driver issue, nor a issue with HG, but the Pi Zero W.

[alzzy]

My issues with cm19a are not range but reliable triggering of cm19a. No led flash no device response regardless of how close i am to tranceiver. P;lease don't derail my issue. Open a new one.

[tuicemen]

I'm not derailing the issue as I experience this with the Cm19 As I have stated, and this is what your OP was about. you stated:

it takes two clicks of an x10 module On or Off button in HG for the cm19a to transmit the command Its like the first click wakes it up and the second transmits the command.

[alzzy]

The driver recognized by win 10 and the one recognized by linux my be different or each OS may respond differently or incorectly to the same code. Please open a new issue.

[alzzy]

In any case in the world of RF comms its always a good idea to send multiple commands.

[alzzy]

And by multiple I mean repetitive. That greatly increases the chance of the signal getting thru.

[tuicemen]

      The driver recognized by win 10 and the one recognized by linux my be different or each OS may respond  differently or incorectly to the same code. Please open a new issue.

The driver HG uses is the same for Windows and Linux (pi)

      And by multiple I mean repetitive. That greatly increases the chance of the signal getting thru.

Agreed

[tuicemen]

@alzzy did HG stable 29 fix your issue?

[genemars]

@tuicemen @alzzy v1.2-stable.30 should fix a few minor issues with X10 and adds security modules DB to restore security modules on reboot/restart. I published as stable, but CM15, CM19 and CM11 should be tested again.

[alzzy]

UGH NO! But it did give me some confidence that the Pi Z can handle the cm19a. It appears to handle the multiple transmits just fine as evidenced by the multiple LED flashes. And when I get the flashes the device is triggered.

I think the command on the first press after a wait time is never getting to the driver. Could be the web gui or some timing issue.

@genemars: Thanks for the improved cm19a driver. I am sure it will improve RF reliability!

[alzzy]

The above was with stable.29. I will update to stable.30 and retest

[alzzy]

Updated to stable.30. Still experiencing unreliable performance to a single click on On or Off.

[genemars]

what browser are you using? Do you know how to use the debugger to see the network requests made when you click on/off?

[alzzy]

I am Using Chrome. Don't know what Tuicemen used. Never used debugger so no,

[alzzy]

Are there directions somewhere on how to use debugger?

[tuicemen]

updated to stable 30 using my phone last night and though unrelated it should be mentioned the installer from inside HG hung on the installing this didn't affect the install as a refresh opened HG with the new version installed. I don't recall having to do that when installing from a windows browser.

I've tested Stable 30 just with the CM15 though have it loaded on another pi for the cm19. the Cm15 still requires a second button press to send a command (wake up) HG. Just for kicks I tested another PI HG that has Zwave switches and they don't require a second press to wake up HG.

Also I'm using the Windows default browser edge but I also experience this from my Android Phone browser.

[alzzy]

I also had the installer hang on both stable.29 and stable.30. Didn't do it on win10 install of the latest win release stable.26