SP6000 Panel Control - Disarm/Arm #18
Comments
|
I see a difference between my MG5050 and your alarm's response for the same packet: Command (same - disarm): Reply (note 0x42 0x0 0x5): Try the following. Stop the script and login to the web console. Once logged in start the script and then try to arm/disarm. I've heard this working for some, it might allude to something else wrong in the script. Worth a shot to try and get to the bottom of this. |
|
Also see: #8 |
|
I'll give that a go |
|
Being logged in seemed to work. Not sure how readable this will be, but here's the log outut. |
|
So I think you linked to the 53 response before which should be thins entry from my log: The two from above: Reply (note 0x42 0x0 0x5): |
|
Interesting, not sure how to proceed though... In another post I thought of combining the v1 and v2 code (leveraging v1's web login), but that just seems very cumbersome, and also I only have an MG panel to test with so it will be very "hit and miss"... |
|
So do we think that there's some flag being set in the web ui that is not being set with our use of the software port? I don't have winload nor a prt3 for serial communication, and I was never able to figure out the codes in the ParadoxMap by using babyware and wireshark. I wonder if the dotNet SDK would yeild any results on what is being passed to the module. |
|
Ok, So I had some code that uses the api, and it actually connects and receives events (very similar ot the script). Would it be useful if I connected and let events come back and wireshark the interactions? Then we can see if they match what is posted, and from there we can look at the arm/disarm code. Attached should be a really short capture of an already connected panel, where I think zone 12 opens and closes This should theoretically match up to this somehow - but I'm not sure I see it: In the wireshark I've only got return communication from the panel to my machine. And I can see the 0xaa 0x25 0x0 0x2 but then it's always 0x33 rather than 0x72. And I'm not sure there in these debug strings from the script where the zone number appears. I think IIRC the 0x4d 0x61 onwards etc is "Main Door" And the bold 0x01 is that it's ON, but I think the zone number is the italics? Was there some encyption is part of their protocol? |
|
Sorry for the delay, was away on business, going to be next week as well.... I had a look at the zip file, but the contents of the data in the steam appears to be encrypted. I think the SDK encrypts by default so there's no way we can really use it to decode any data. The only way would be to download winload and disable the encryption flag (in its COM.ini file), then wireshark the link whilst you do a arm/disarm. We can then look at what is being sent and figure out the issue. |
|
Hmm winload doesn't seem to know what an IP connection is. It's all modem based. |
|
I notice the messages being sent to the panel is "@" - is that consistent with yours? |
|
In winload the IP connection is in another tab, next to the modem connection. Once the new alarm/panel is created there's a drop-down on the right top of the page. Select IP there. I haven't noticed any @ signs. Most transfers are not ASCII, so I only really look at the hex. |
|
Yeah I saw that. But under the connection methods it only lists modems/gprs modems which are all COM based. I've actually managed to do everything I need with a c# sharp based program using their sdk. I managed to figure out the arm and disarm commands today. Unfortunate to moved away from the python solution though. So I should keep plugging away. Also what the sdk has shown me is that the panel quite often posts a ready, or armed status. So if the script misses the arming command, there's a periodic reporting of the area status. |
|
I finally got winload to run. So when i get a chance I'll wireshark an arm or disarm. |
|
Tried it today the script works ok with the SP6000 except for control. |
|
Get anywhere on this? When you talk about resetting the password do you mean in the script, or actually in the IP150- module? |
|
No actually gave up on it. I was talking about the 911 register on the panel it’s self. That register is whats used to authenticate winload and other devices connected to the panel. I use it to authenticate through uart connection. |
|
Yeah I wonder what in the set up communication is the pc password and panel id. In wireshark I can see the ip modile password unencrypted, but can't see where these other values are. I wouldn't want to remove them from my panel (the 911 register etc) |
Here's the debug log when attempting to disarm Partition 1. Looks like the command is being accepted.
The text was updated successfully, but these errors were encountered: