| Author |
|
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 23 2010 at 18:39 | IP Logged
|
|
|
I'm trying to get PH to talk with my JDS controller. I've tried opening a port with the complicated and simple method:
ph_comopensimple(1, 3, "9600,N,8,1", "null_mac")
I don't really have a macro to run in response received bytes, so I made up a fake one.
If I use Docklight to send this string "##%2b02080e020000." (.= CR, or 0D in hex) it works just fine.
If I use PH to send the same string like this:
PH_comsendstring(1, "##%2b02080e020000\x0D")
I get gibberish response from the controller. It looks the same both ways when I monitor the port to look at the traffic, so I am really confused at this point.
The only thing I can think of is that PH is packaging bytes differently, but I don't know how to test for that. Really baffled on this one - suggestions welcome.
Mitch
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 23 2010 at 21:16 | IP Logged
|
|
|
Mitch,
I looked at the code concerning this (cant actually test since I don't have a JDS controller) and cant see where the problem would be. Im not familiar with DockLight so Im not sure how it would actually be sending your string. It looks as if you might be trying to send hex bytes but it may just be a hex string...not sure. The way you've got your PH string declared looks proper. It will send the characters as you've typed them followed by a carriage return. Is the above string exactly what should be sent to the JDS or should some kind of conversion be done?
Let me know and Im sure we can get it worked out.
Dave.
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 23 2010 at 21:56 | IP Logged
|
|
|
Yes, you have it right - I'm trying to send this string "##%2b02080e020000" followed by a return.
Docklight Scripting is a serial communication package - allows you to view/send data in ascii, hex, etc. The only difference I can think of is that I pasted messages into Docklight in hex, but that should not matter. I was using a serial port splitter to send data from three applications to physical port com 1 for testing purposes. I tried it after rebooting without the port splitter active, but PH still sent the same gibberish. When I watch communications with a port monitor I cannot tell the difference between the strings sent by PH and the strings sent by Docklight or the JDS software. The latter two produce the desired responses by the controller, but PH does not. All three are set to 9600 baud, N, 8, 1. Is there some other setting I should be messing with using ph_comopen()?
Thanks!
Mitch
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 23 2010 at 23:26 | IP Logged
|
|
|
Mitch,
I looked up the Stargate protocol and could see that the command you're trying to send is an advanced X10 command so I think Im looking at the right protocol. If so, the protocol says that the correct baud rate should be 2400 instead of 9600. Can you try settings of 2400,N,8,1 and see if that makes a difference?
Thanks,
Dave.
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 24 2010 at 00:56 | IP Logged
|
|
|
I tried that again just to convince myself. That documentation is for an older model controller, but the baud rate that works is 9600 for the model I have. Most of the commands are the same. Again, communication with a serial communications utility works just fine, but the strings from PH get jumbled somehow. They cause unexpected responses or no response from the controller. I cannot see the actual string being interpreted, but I can see the response. I'm still puzzled.
Thanks for your help.
Mitch
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 24 2010 at 17:53 | IP Logged
|
|
|
Hi David,
I've done some more testing and have come up with a hack that works ok. I can get my macros to send commands to the controller via the serial port consistently if I run them from the 'Run' window in PH, but the same macro will not work if it runs in response to a trigger from an Insteon device. So, I added a delay at the beginning of the macro and that seems to fix it. I first used 1 second (delay=1000), and that worked fine. I was able to reproduce the bug by reducing this to 0.1 sec (delay=100), and it persisted at 0.25 sec. I get consistently good communication with delay=500, so I think I will go with that.
This is fine for me but I guess it does raise the question of what PH is doing. You would not think that an incoming Insteon message and trigger response would interfere with serial communication, but it seems to.
Thanks for your quick response and help on this. Hope you have a great holiday!
Mitch
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 26 2010 at 19:30 | IP Logged
|
|
|
Another followup question - how do I get PH to run a macro (opens the com port) when it starts? I'm probably just using the wrong key words, but not finding this answer in the forum or wiki.
Thanks!
Mitch
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 26 2010 at 19:59 | IP Logged
|
|
|
You used to just create a macro called STARTUP. Now, it's specified in the pwrhome.ini file...
Code:
[Script]
MAXRECURSION=30
GLOBALVARMAXSUBS=25
MACROJUMPLIMIT=0
STARTUPMACRO=STARTUP
SHUTDOWNMACRO=SHUTDOWN
REINITMACRO= |
|
|
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 26 2010 at 21:44 | IP Logged
|
|
|
Thank you!
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 27 2010 at 15:40 | IP Logged
|
|
|
I tried this - created a macro called 'startup' to open a com port, modified the ini file as you described, and nothing. I still have to run 'startup' after ph starts to open the port. I tried putting a 10 second delay before opening the port, but that did not fix it. Suggestions?
|
| Back to Top |
|
| |
smarty
Super User
Joined: May 21 2006
Location: United States
Online Status: Offline
Posts: 728
|
| Posted: December 27 2010 at 15:52 | IP Logged
|
|
|
You should set up a PH trigger based off the system process of "startup". You can also set up a trigger for a macro to run at the system process of "shut down".
Tony's method might work, but I think it was prior to having the system process triggers.
__________________
Elk - Insteon - BlueIris - DMC1 - PowerHome - XLobby - HA_Bridge w/Dots - Brultech
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 27 2010 at 19:01 | IP Logged
|
|
|
Doh! That's right. I'm getting old... ;)
|
| Back to Top |
|
| |
Mitch
Groupie
Joined: September 26 2010
Online Status: Offline
Posts: 43
|
| Posted: December 31 2010 at 01:00 | IP Logged
|
|
|
I'm still curious about what appears to me to be a bug in PH. If I send serial data using the macro from the run window I do not need to delay the send - it works perfectly every time when sent immediately. If I run the same macro in response to a trigger on an incoming Insteon message then I have to delay the ph_comsendstring() command by at least one second to get consistent results. If I do not delay then the receiving controller responds unpredictably like the data being sent has been corrupted. I would really like to be able to send these commands without the delay for a faster response on a button or paddle press. Has anyone else had this type of issue with the ph_comsendstring function?
|
| Back to Top |
|
| |
smarty
Super User
Joined: May 21 2006
Location: United States
Online Status: Offline
Posts: 728
|
| Posted: December 31 2010 at 11:51 | IP Logged
|
|
|
Just a thought....but check your event log to be sure....
For Insteon triggers there have been reports (and I also routinely see this) where the incoming Insteon signal arrives twice and then causes the PH trigger to fire twice. If you have multiple trigger fires back to back, this could be the cause of your COM issues.
I am eagerly awaiting the next relase of PH where this duplicate Insteon trigger fire is supposed to be fixed (I believe). In the mean time, there is a work around using the "ph_macroparm("TRIGGER-DISABLE",1,0,0,0,0) + 1" command where "TRIGGER-DISABLE" = is a short 3 line macro that disables and re-enables the trigger for a user defined time period. Query the forum for Dave's "TRIGGER-DISABLE" macro.
Hope this helps.
__________________
Elk - Insteon - BlueIris - DMC1 - PowerHome - XLobby - HA_Bridge w/Dots - Brultech
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: PH_comsendstring not working
