Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 26, 2020 13:09:02 GMT -5
Thanks for taking the time to research this Rod. However the protocol isn't really secure, sure it's certainly not open source but it is doable (apparently), unless you mean the protocol in encrypted, which it isn't. Yes there certainly is other electronics that could be used but the alarm is already implemented throughout the building and is also large expense already so ripping it out and replacing it isn't an option. Jeff Bezos has delivered the cables etc that I need to set this up via RS232, this should enable me to test with this software to at least read the info leaving, however I'm unsure if the RS232 will be different to IP signalling, theory is it should be the same...... Any suggestions on an RS232 port monitor? I used to use PortMon from SysInternals, but that doesn't seem to run on Win10. Aslo, yeah mobiles suck at this kinda browsing!
|
|
Tasp
Full Member
Posts: 215
|
Post by Tasp on Feb 27, 2020 15:32:46 GMT -5
Well, just as a small update. I managed to run the openGalaxy software and sniff the RS232 info, however what comes across the RS232 a little different while the majority of the same info comes across it's slightly different. It's close enough to what LB is receiving. It returns back to the alarm with; Which when I transmit that back via RS232 it reacts correctly, however when sending this back thru IP it does nothing. And yes I've tried with <CR><LF> as well. So yet another dead end
|
|
Tasp
Full Member
Posts: 215
|
Post by Tasp on Mar 7, 2020 12:12:36 GMT -5
Ok, so the original DC09 document that I've been referring to appears to be a new version and not implemented by many manufacturers yet, so hence the reason why my data looks different to that doc. I'm really sorry for misleading you all. They all seem to be using an old standard. DC03 or DC05. I've found 2 recent sites link here and link here, the first one is using a wrapper to change it from SIA to a different manufacturers protocol but it gives some ideas on usage, the latter actually appears to be for a FLEX type panel which is the newer model of the one I'm working on, but appears to be solely using the SIA format. I've attempted to rewrite this code into LB, but obviously it's not working!! (surprise, surprise). After alot of messing around it simply seems to do the same thing as the code Chris posted! In that code it seems to write and then read from an array. I think this is just to keep track of the data. Except thats when it gets confusing. This code is written in TypeScript (Javascript derivative). import { FunctionCodes } from "../functionCodes";
const BASE_PARITY = 0xFF; const HEADER_LENGTH = 2; const PACKING_LENGTH = HEADER_LENGTH + 1; const CHECK_OFFSET = 0x40;
export class SIABlock {
constructor(public funcCode: FunctionCodes, public data: string) { }
toBuffer() { const dataLength = this.data.length; const bufferLength = dataLength + PACKING_LENGTH; const checkLength = dataLength + CHECK_OFFSET; let buffer = Buffer.alloc(bufferLength);
buffer.writeInt8(checkLength, 0); buffer.writeInt8(this.funcCode, 1);
let parity = BASE_PARITY; parity ^= checkLength; parity ^= this.funcCode;
this.data.split('').forEach((char, index) => { buffer.write(char, index + HEADER_LENGTH); parity ^= buffer[index + HEADER_LENGTH]; });
buffer[bufferLength - 1] = parity;
return buffer; }
static fromBuffer(buffer : Buffer) {
const dataLength = this.checkParity(buffer); const funcCode = buffer[1]; const data = buffer.toString('utf8', HEADER_LENGTH, HEADER_LENGTH + dataLength);
return new SIABlock(funcCode, data); }
static checkParity(buffer : Buffer) {
let dataLength = buffer[0] - CHECK_OFFSET; let parity = BASE_PARITY; let bufferLength = dataLength + PACKING_LENGTH;
for (let i = 0; i < bufferLength; i++) { parity ^= buffer[i]; }
if(parity != 0) throw "Parity Error";
return dataLength } }
This is Chris Inversons implementation ackFlag = hexdec("40") messageSize = 0 msg$ = ""
'Removed the padding, apparently it doesn't need it. Doesn't work either way! 'for x = 1 to 56 ' msg$ = msg$ + chr$(0) 'next x
header = ackFlag + messageSize functionCode = hexdec("38")
parity = 255 parity = parity xor header parity = parity xor functionCode
for x = 1 to messageSize parity = parity xor asc(mid$(msg$, x, 1)) next x
block$ = chr$(header) + chr$(functionCode) + msg$ + chr$(parity) print "block$:";block$
The only difference I see is Chris's code adds the empty chars up to the expected message size, but I don't think this is needed. I've also been advised this; Which I'm pretty sure is what the above code gives, but it doesn't work!!!! Am I missing something glaringly obvious here?
|
|