X10 Community Forum
📱🖥️PiX10Hub => 🏥Help and Trouble Shooting => Topic started by: Geewiz on January 08, 2019, 01:55:11 PM
-
I have my Raspberry Pi Zero W loaded with the PiXHub image and everything seems to be working. I can access HA-Bridge and Home Genie and have created my first light control module.
Now I'm trying to figure out how to get Alexa working and keep doing searches in circles. B:( I'm getting dizzy and any quick guidance on the process to put it all together would be GREATLY appreciated!
Thanks!
-
I'm in the same boat. If u learn anything useful post it. I will do the same. B:(
-
Have you looked at the HA-Bridge tutorial?
http://forums.x10.com/index.php?topic=30664.msg178626#msg178626
failure to enter the correct ip of your pi will cause hours of frustration.
-
Ok so the bridge is working and I can turn a lamp on/off from the bridge gui. I added the dim item. When i do a Test Dim from the bridge a screen pops up to select dim level. I set level to 50 and click OK. Get flag that says command Executed but lamp does not dim. What am I missing?
-
Are the Lamp Modules the newer Soft Start ones where they ramp On and Off or the older ones that go to 100% and then get dimmed down?
I don't know what is bring sent. If it is an Extended X10 command to dim to set a level. The older ones will not do anything with an Extended X10 command. Only the Soft Start ones will. If a On is sent and a series of Dim commands are being sent. Then both types should respond.
-
Brian, thanks for the reply! I don't know if its extended or not, but the module is an old module and not soft start. I send an on command from the bridge. It Turns on. I then send it the dim command as described by me in last post it does not respond. So what am I doing wrong?
-
I don't know enough about the bridge. On how to determine Lamp Module type or what is sent.
So I can't say if it is sending a single Extended X10 Dim Level command or a stream of Dim commands to step the old Lamp Module down to the dim level you wanted from 100% On.
From your description it maybe sending the single Extended X10 dim level command.
Do you have any other controller that you maybe able to monitor the X10 command when they are sent?
-
AHP activity monitor with cm15 captures on and off commands but does not record any dim commands. The interface I use with the hub is a cm11a. So can the Pi really control the cm11 wrt dim or is it sending the wrong info to cm11?This is what is in the bridge Dim Item slot. And the IP is correct.
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.Dim
-
I suggest you brush up on the HA-Bridge dim calls found in its documentation.
there are at least three ways of sending Dim commands which adds to the confusion you may also wish to look at the HG documentation for dim command as there are two methods the set level I would expect would work better with HA-Bridge.
However I can't be of any more help then that as I don't use dim/brighten commands in my setup.
Does dim work from inside HG?
If you don't have the device setup as dimmable in HG then it will ignore dim commands to that device I suspect.
-
If you have the module set as an on/off rather than dimable, it will not have any way in the interface to control dim within HG. You can still send the dim command with an external controller. HG will see all commands sent over PLC if you use a CM15A but I do not know if the interface would do anything with them (assume not since it doesn't have a dim level for the module). I don't use dim so I can't say how the dim commands other than those on the widget work.
-
I have been trying to dim from the bridge. Are those commands processed by HG or do they go to the cm19a via some scrip that bypasses HG? B:(
-
I have been trying to dim from the bridge. Are those commands processed by HG or do they go to the cm19a via some scrip that bypasses HG? B:(
:o
The commands in HA-Bridge go to what ever is in the on/off/dim call scripts. nothing in the script nothing gets sent.
if your script points to mochad the call gets sent to it then the cm19.
if the script goes to HG then HG handles the Cm19.
the only Hardware HA-Bridge will auto connect to is an Alexa device and even then it has to be given device names.
-
So the Pix10Hub image comes with example entries ith the Bridge. This is what is comes with and this is what I have been trying:
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.Dim.
What sw on the hub is processing this command/script?
-
Is your pi IP 192.168.0.10 ?
the port should be correct unless you changed the HG port.
The backups were meant as examples
the IP has to be changed as well as the X10 address.
you can try a simple test from your PC web browser. Just copy the call into the browser press enter and see what happens.
I believe it should dim your lamp by 10 % if set in HG correctly
-
Is your pi IP 192.168.0.10 ? No 192.168.1.10 and thats what I have in the Bridge entries as I sited above.
the port should be correct unless you changed the HG port: I did not change the HG port. I access HG at port 8080
The backups were meant as examples: Examples aren't useful unless they fundamentally work!
the IP has to be changed as well as the X10 address: As I said several times the Bridge works with on / off not with DIM. The IP and port are the same in all 3 cases.
-
I put the on or off bridge item in browser Lamp responds! I put Dim entry and get this:
{"Status":"Error","Message":"{\"ClassName\":\"System.FormatException\",\"Message\":\"Input string was not in a correct format.\",\"Data\":null,\"InnerException\":null,\"HelpURL\":null,\"StackTraceString\":\" at System.Number.StringToNumber (System.String str, System.Globalization.NumberStyles options, System.Number+NumberBuffer& number, System.Globalization.NumberFormatInfo info, System.Boolean parseDecimal) [0x00057] in <52f79f713f22467ab348e590c85015fb>:0 \\n at System.Number.ParseInt32 (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00015] in <52f79f713f22467ab348e590c85015fb>:0 \\n at System.Int32.Parse (System.String s) [0x00007] in <52f79f713f22467ab348e590c85015fb>:0 \\n at MIG.Interfaces.HomeAutomation.X10.InterfaceControl (MIG.MigInterfaceCommand request) [0x0074d] in <c86d986153dd46358f54499cd8a040dd>:0 \\n at MIG.MigService.Gateway_PreProcessRequest (System.Object sender, MIG.ProcessRequestEventArgs args) [0x003f9] in <01eec8bfa28f444d82b2dc82f7810fbf>:0 \",\"RemoteStackTraceString\":null,\"RemoteStackIndex\":0,\"ExceptionMethod\":null,\"HResult\":-2146233033,\"Source\":\"mscorlib\"}"}
-
If I follow the Control.Dim with a space and a number it does not dim but it does not throw that error. Webpage responds with {"ResponseValue":"OK"}. Does that help any?
-
It is impossible for anyone I know of to include a sample backup which will work for everyone.
You were in the test group If you had an Objection to the sample backups being included you should have voiced you opinion then and I wouldn't have included anything in HA-Bridge. Also the tutorial states these addresses must be changed to work correctly.
I'm not sure how your on off calls are working if they're no using the Pis IP B:( but then you've been getting lots of strange goings on.
The error message your getting back in your browser does indicate a issue with the call.
be sure there is no space or character after the word dim also many calls are case sensitive try the word dim instead of Dim.
You don't state if you've looked at the HG documentation for api calls. I know there is a level call and I think a bright call try those as well.
-
If I follow the Control.Dim with a space and a number it does not dim but it does not throw that error. Webpage responds with {"ResponseValue":"OK"}. Does that help any?
I'm afraid I can't help with HG or HA-Bridge dims anymore then I've already suggested.
I spent several months attempting to figure out dim calls to the HA-Bridge from Alex10 and I don't use dimming so I'll not waste another few months again on something I don't use and possibly never will.
-
So the Pix10Hub image comes with example entries ith the Bridge. This is what is comes with and this is what I have been trying:
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.Dim.
What sw on the hub is processing this command/script?
That command will use HG's API interface to send a dim command to X10 device B16. If HG doesn't have a dimmable module on B16, I do not know if it will perform any action (I only send commands to turn the lights up to full bright via the "100% on" script that is included in HG). I would recommend trying the same API call with an ON or OFF command to verify that HG is able to control the module.
I do not remember the exact format for the command but I believe it's just:
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.On (http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.On)
If that doesn't work, you should be able to find it in the documentation.
-
I AM using the Pis IP . I said that several times. Its at 192.168.1.10 and static. Have been using it since day 1!!
I came in late to the test group and only got my Pi a day or so before 12/22. so I did not have time to do a lot of testing. If I had found it I would have objected!
I am not getting lots of strange results, more like 3. Two related to dimming, 1 the double click problem with the cm19.
I will look at the HG api calls and see what I can find out.
-
So although I don't use dim with my dimmable modules, it appears the following works on my system. I replaced the IP with yours so they should be able to just be clicked on. If your HG is located somewhere else, make sure you change it in the browser prior to sending or else you will get no response.
Dim to 100%:
http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.Dim/100 (http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.Dim/100)
Turn module on:
http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.On (http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.On)
Turn module off:
http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.Off (http://192.168.1.10:8080/api/HomeAutomation.X10/A2/Control.Off)
List all interfaces:
http://192.168.1.10:8080/api/HomeAutomation.HomeGenie/Config/Interfaces.List (http://192.168.1.10:8080/api/HomeAutomation.HomeGenie/Config/Interfaces.List)
List all modules:
http://192.168.1.10:8080/api/HomeAutomation.HomeGenie/Config/Modules.List (http://192.168.1.10:8080/api/HomeAutomation.HomeGenie/Config/Modules.List)
This is all in the HG documentation on Gene's site. I highly recommend reviewing it as it will give you a lot of answers to things that people here may not be familiar with. I used the site to give you these commands as I don't generally use them myself.
https://genielabs.github.io/HomeGenie/api/mig/core_api_config.html (https://genielabs.github.io/HomeGenie/api/mig/core_api_config.html)
-
The dim call that works from the browser is:
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.Level/35 for example. I will enter into bridge and retest. Thanks for the help. Now I know what an API is.
-
It does NOT work from the bridge "Test Dim" button. I will see If I can command a dim from HG gui next.
-
It does NOT work from the bridge "Test Dim" button. I will see If I can command a dim from HG gui next.
Try /A1/Control.Level/50
-
Petera, yes that is what i tried a few posts earlier with some success.
Now From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge.
-
The dim call that works from the browser is:
http://192.168.1.10:8080/api/HomeAutomation.X10/B16/Control.Level/35 for example. I will enter into bridge and retest. Thanks for the help. Now I know what an API is.
That Dim call is a one step increment. No numbers associated with it. You woudnt even notice it. The Level call allows you to define what percentage between 1 and 100.
I've posted so many links to the HG documentation. This is in the MIG API section. I just wish people would read them. Maybe you could let others know if you were successful.
-
Petera, yes that is what i tried a few posts earlier with some success.
Now From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge.
Did I already suggest to you to disable the bridge and address directly between HG and the CM19
-
Please read my earlier posts. Thanks.
-
Level is the command that would be used in programming but I couldn't find a reference to what should be used in the API other than what was in the documentation I linked. As for the delay, I can't help you there as I don't know how the HA-Bridge is designed to communicate. HG is very quick to interpret an incoming command to an outgoing command generally. If the command is sent promptly I have no idea why it would be delayed. IMO, you would be best to watch the commands on the PLC either from a second CM15A as a monitor, or a XTBM, or HG's logging, or etc. Without knowing what is actually being sent it's difficult to diagnose the issue especially since I have never looked at your software (HA-Bridge) or hardware (Alexa).
-
bkenobi-Thanks for the help! I understand what you are saying and agree. i will see if i can do some more monitoring.
petera- as i said earlier the Control.Dim when entered into the browser returns an error.
Thanks for all the help!
-
Level is the command that would be used in programming but I couldn't find a reference to what should be used in the API other than what was in the documentation I linked. As for the delay, I can't help you there as I don't know how the HA-Bridge is designed to communicate. HG is very quick to interpret an incoming command to an outgoing command generally. If the command is sent promptly I have no idea why it would be delayed. IMO, you would be best to watch the commands on the PLC either from a second CM15A as a monitor, or a XTBM, or HG's logging, or etc. Without knowing what is actually being sent it's difficult to diagnose the issue especially since I have never looked at your software (HA-Bridge) or hardware (Alexa).
Control Level works in this case as does Control Toggle for on/off or Control Off just to turn it off.
Control Bright is the one step bright and opposite to Control Dim and so on. All in the documentation.
I assume that the OP has solved his dilemma and now knows where to find all these Automation commands. Of course as you say they can all be encompassed in one single automation program.
-
bkenobi-Thanks for the help! I understand what you are saying and agree. i will see if i can do some more monitoring.
petera- as i said earlier the Control.Dim when entered into the browser returns an error.
Thanks for all the help!
Fine but can we agree that the Control.Level sorts out your issue. Yes or no. Remember you can't be kinda pregnant.
-
petera-I am not sure....
1.as Control.Dim is in the api but throws an error in the browser so is the api wrong or is the response wrong?
2. Control.Level appears to solve the dimming issue but I need to test with Alexa.
and
3. as i said:
"From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge." this type of performance IS an issue for me!!
-
petera-I am not sure....
1.as Control.Dim is in the api but throws an error in the browser so is the api wrong or is the response wrong?
2. Control.Level appears to solve the dimming issue but I need to test with Alexa.
and
3. as i said:
"From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge." this type of performance IS an issue for me!!
For the moment forget about the HA Bridge. Disable it as advised. Now issue the commands from the browser address bar. You shoukd get the ok response and yiur light should dim. In the HG api issue the same commands. You should get the same or similar reaction time and your light should dim.
I won't comment on the HA Bridge other than to say it sounds like you are experiencing some form bottleneck or latency between HA Bridge and HG which you will need to trace.
-
petera, Thanks again for the help! I think I will first attack the performance issues with the gui and also with the cm19 by returning/replacing my Pi zero W board as I seem to be the only one having these issues and in that case it most likely is a defective Pi. B:(
-
petera, Thanks again for the help! I think I will first attack the performance issues with the gui and also with the cm19 by returning/replacing my Pi zero W board as I seem to be the only one having these issues and in that case it most likely is a defective Pi. B:(
Forgive me if I'm veering off here but will just throw out my experience. I started with the Pi Zero W board and the .iso provided by Tuicemen. Just using the HG gui, I could never get a reliable control over any of my X10 devices. At best I would have to send two commands to get a light to turn on/off. Sometimes it would take more.
My Pi Zero was located about 6 feet away from my wireless AP, so I don't think that was the trouble. I also had some other problems, but generally the Pi Zero just seemed slow, like it is struggling and working too hard.
So I started it all over over, this time with a Pi 3 B+. I knew that Tuicemen's .iso wouldn't install cleanly on the 3, so steeled myself to make a go of it from scratch. This was daunting as I've never had any Linux experience.
Anyway, I have the full Stretch version of Raspberry installed and have installed HG. The Pi is attached directly to the network, thanks to this model having a network connector.
Everything is working very well. It has been totally reliable, no hiccups, and is surprisingly speedy and robust.
The last step now is to get HA-Bridge installed and working with Alexa. This step is a bit daunting for me, but probably made more difficult simply due to my unfamiliarity with Linux.
Once this is accomplished, I can turn off the PC that I've had running 24/7 for years!
-
Geewiz if the only reason for HA-Bridge is for Alexa control there is a better route using a HG addon HomeGeniEchoBridge I've been using it now for a few days and it is much faster then HA-Bridge the only thing you need to put in is HG ip and port
-
how do you install it?
-
On my phone right now Ill post a how to later today.
-
No problem man! thanks!
-
Geewiz if the only reason for HA-Bridge is for Alexa control there is a better route using a HG addon HomeGeniEchoBridge I've been using it now for a few days and it is much faster then HA-Bridge the only thing you need to put in is HG ip and port
When I was a small boy, my father (a mechanical engineer) had a sign in his workshop that said...
THINK...
There must be a harder way
It took me a long time before understanding how frequently I fall into that mind-set. B:( >*<
Thanks, Tuiceman!!!
-
ok have a bit of a walk through written up.
http://forums.x10.com/index.php?topic=30670.msg179911#msg179911
I found it took a while for the interface to find all my devices in HG so I suspect that may be reflected by the size of ones setup.
Once setup I let it run over night and did a rediscovery of devices with Alexa and she found them all.
initially she didn't find any.
-
petera-I am not sure....
1.as Control.Dim is in the api but throws an error in the browser so is the api wrong or is the response wrong?
2. Control.Level appears to solve the dimming issue but I need to test with Alexa.
and
3. as i said:
"From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge." this type of performance IS an issue for me!!
For the moment forget about the HA Bridge. Disable it as advised. Now issue the commands from the browser address bar. You shoukd get the ok response and yiur light should dim. In the HG api issue the same commands. You should get the same or similar reaction time and your light should dim.
I won't comment on the HA Bridge other than to say it sounds like you are experiencing some form bottleneck or latency between HA Bridge and HG which you will need to trace.
Ok so I have a brand new Pi Z W and a new power supply. I have the Bridge disabled. From the browser I get anywhere from about a 1 sec. to about 8 sec. response to dims. I also have seen about the same spread with On/Off although the longer times are alot less frequent.
-
Are you using the CM15 or the CM19? I've found delays to be fairly common with the CM19 but unplugging if from the Pi for 10 seconds restores it to near instantaneous.
-
petera-I am not sure....
1.as Control.Dim is in the api but throws an error in the browser so is the api wrong or is the response wrong?
2. Control.Level appears to solve the dimming issue but I need to test with Alexa.
and
3. as i said:
"From the HG gui with that command in the bridge, it does kinda work. It can take up to 10 seconds or more for a response from the device and sometimes, although widget registers a command, the device never responds. And that's not just to dimming but to On/Off. Not very reliable from the gui. Seems very reliable from the browser. Won't dim from the bridge." this type of performance IS an issue for me!!
For the moment forget about the HA Bridge. Disable it as advised. Now issue the commands from the browser address bar. You shoukd get the ok response and yiur light should dim. In the HG api issue the same commands. You should get the same or similar reaction time and your light should dim.
I won't comment on the HA Bridge other than to say it sounds like you are experiencing some form bottleneck or latency between HA Bridge and HG which you will need to trace.
Ok so I have a brand new Pi Z W and a new power supply. I have the Bridge disabled. From the browser I get anywhere from about a 1 sec. to about 8 sec. response to dims. I also have seen about the same spread with On/Off although the longer times are alot less frequent.
Ok so the Control.Level is working on dim so I'm now suggesting latency is between the CM19 and your transceiver. You've confirmed that HG to CM19 comms is working so I suggest you start looking at repositioning your transceiver or changing your house code. You could have noise on the PL from the transceiver to the lamp module.
You could run HG in debug mode and watch the commands being received and the time it takes for them to be acted on. You can watch the gateway being opened and see the response times. To do this it's
sudo systemctl stop homegenie.service
cd /usr/local/bin/homegenie
sudo mono HomeGenie.exe
-
I am using cm11a.
-
Have been for the past week.
-
I am using cm11a.
Ok so it's pure PL comms. Run the debug anyway and post a sample of the X10 traffic from the debug. Again I wouldn't rule out noise, house code problems either. You're experiencing the same issues with the CM19. Is that correct.
-
The latency is in the Pi Zero. When I enter the command with the browser, it responds with a "waiting for 192.168.1.8" which is my Pis IP. At the same time that message disappears the device responds. I don't believe the Pi zero is up to the task of running HG. When it sends a response to the browser, the device responds to the cm11a. And that can take up to 8 or so seconds.
-
I cannot confirm that the cm19 responds the same. I stopped using it cuze it was never claimed to be compatible with the hub and also it limits the capability of the system.
-
The latency is in the Pi Zero. When I enter the command with the browser, it responds with a "waiting for 192.168.1.8" which is my Pis IP. At the same time that message disappears the device responds. I don't believe the Pi zero is up to the task of running HG. When it sends a response to the browser, the device responds to the cm11a. And that can take up to 8 or so seconds.
Just run HG in debug mode as I suggested and post the X10 results. I can see gateway responses from there.
Here's some basic automation to play about with. Just read and follow the examples
http://old.homegenie.club:8080/www.homegenie.it/forum/HomeGenieHelp18c5.doc?action=dlattach;topic=1420.0;attach=2219
-
petera- When you have a second please take a look at the attached HG Debug and tell me what you think. thanks!
-
petera- When you have a second please take a look at the attached HG Debug and tell me what you think. thanks!
I've just had a quick look at the file. Are you running the Energy Monitor and the Philips Hue programs.
-
Not the energy monitor, but i left the other items that came with it there so I could study them.
-
Your gateway responses between 0.5 secs and 1.75 secs are well within the expected response times.
My suggestion is that you disable any programs in HG that you are not using.
Also could you try plugging your CM11 into different outlets around the house and measure response times. You could also create a test X10 Lamp Module in HG and experiment with different house codes to rule that out.
Could you open the Programs page in HG and do a screen cap and post here so I can see what programs are running on your system.
-
Attached is my programs page.
-
different outlets around the house and different house codes- didn't help.
disabled all programs in HG that I am not using- Mad a huge improvement, only experience an occasional long response time! so it is a processor issue?
-
FYI disabling the programs did not improve cm19a performance
-
FYI disabling the programs did not improve cm19a performance
Some of the standard installed programs on HG are making a lot of web calls to the server and as a result the Pi Zero W really isn't suitable for this type of application when you add other factors into the equation.
Possibly stripping HG back to the X10 basics and along with the CM11 or the CM15 you'd probably get away with it.
My own recommendation would be a Raspberry Pi 3b or 3b+ which would more than cover your needs and allow you to run your system comfortably with a CM19 too. That's roughly what my setup consists of.
You could always repurpose your Pi Zero W as a standalone HA Bridge server or there's plenty of other Pi projects out there that would comfortably interface with HG too.
-
petera- Thanks for all the help! I really appreciate your effort. Maybe adding the deleting of unneeded programs to the Hub setup instructs would be a good idea. it would have saved me a lot of troubleshooting and the getting of a replacement Pi Z W.
I might try installing the HG Echo Bridge and disabling the HA bridge. That may also save on processing power. What do you think?
Thanks again. :)%
-
petera- Thanks for all the help! I really appreciate your effort. Maybe adding the deleting of unneeded programs to the Hub setup instructs would be a good idea. it would have saved me a lot of troubleshooting and the getting of a replacement Pi Z W.
I might try installing the HG Echo Bridge and disabling the HA bridge. That may also save on processing power. What do you think?
Thanks again. :)%
Yes when looking at hardware suitability it's important that the correct unit is selected for the job. Other than basic X10 module control the Pi Zero W doesn't cut it.
There's varying reports on the success and failure of the EchoBridge with HG. While some have reported it working they have not indicated what generation Alexa device they are using, what model and what country they are based in.
It's one thing telling people you go it working and another setting out exactly how you achieved this including your hardware setup and what other ancillary products you have working on your LAN.
There's no problem installing the EchoBridge MIG program and trying for yourself. Just download the zip file and in the Settings section down at the bottom right hand side of the screen select Options and Install package. You've nothing to loose either way.
Just back up your system in case you want to revert should it not work