Add unit testing

[simonhac]

@anthonywebb i am refactoring some code in order to prepare for issue #13. i'd like to include some unit tests. i've written hundreds of unit tests in java, but never in JS.

i was going to have a crack at mocha.js, but have been convinced to invest my time in tape instead.

do you have any strong feelings here?

[anthonywebb]

No strong feelings either way. Tests would be great.

[simonhac]

@anthonywebb i'm doing some refactoring, just wondering how you'd feel about open just a command port and changing the event level e5s1c1 -- then we wouldn't need to worry about maintaining three open sockets to cgate.

[anthonywebb]

I guess I would have to dig deeper into what the other sockets are being used for. Does everything we need come across the command port? For some reason I thought we needed the others, but I'd have to look closer.

…

On Fri, Jan 27, 2017 at 4:52 AM, simonhac ***@***.***> wrote: @anthonywebb <https://github.com/anthonywebb> i'm doing some refactoring, just wondering how you'd feel about open just a command port and changing the event level e5s1c1 -- then we wouldn't need to worry about maintaining three open sockets to cgate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAARLXte0rTo3aaRZ-k0IAUuYz4v0_WNks5rWdp1gaJpZM4Lvb3P> .

[simonhac]

@anthonywebb presently the code opens three sockets. by sending the 'events e5c1s1' (or perhaps a higher level e-value) to the control port, i think we get exactly the same information and there's only one socket to manage.

i'll give it a go and let you know how it works.

should make #14 easier to solve.

[gbrooker]

Please make sure it doesn't break the PIR security sensor. When I wrote the module I noticed that the presence detection messages were pushed on a different socket to the other messages.

[simonhac]

thanks @gbrooker -- i don't have any PIR security sensors. are you able to please post some (all?) example c-gate messages for security and i'll do my best not to break them? (my proposed restructuring is fairly significant, so i'll definitely be touching the related code, and most likely accidentally breaking it. 😬)

if you can, please also let me know which socket the messages arrive on.

[gbrooker]

Sure they look like

# security zone_unsealed //BVC13/254/208/3 #sourceunit=8 OID=

And come through on the events channel. Details of this are in the CGate user guide, page 218

http://www3.clipsal.com/cis/downloads/Toolkit/CGateServerGuide_1_0.pdf

Cheers
Guy

[simonhac]

thanks @gbrooker. out of interest, what security system do you have integrated?

[gbrooker]

I have a PIR motion detector 5753 on the CBus, the rest of my security system is not connected to CBus at the moment.

[simonhac]

hi @gbrooker that's interesting -- i have several 5753 PIR motion detectors. i've never thought of them as security sensors.

interestingly, i don't get any security messages via c-gate. i looked into my setup a little deeper and see that it was commissioned with everything in the lighting application (56) and not the security application (208). i don't know if that was intentional, but i wonder if that's why i'm not getting any security messages?

(btw, i am using v1.1.0 of the manual, released october 2013 and available in the cgate zip file. the link you gave above is to v1.0 from march 2006.)

[simonhac]

@gbrooker i've had a look at my 5753L sensors and i can't work out how to get them to generate security application messages. mine are all in the lighting application (56). i tried to move one to the security application (208), but c-bus toolkit won't let me.

so how is it that you get security zone_unsealed messages while i don't?

are you absolutely sure that it is your 5753L sensors that are generating the events?

(important that i solve this as otherwise my proposed changes -- coming soon -- might break your install.)

[simonhac]

@gbrooker i'd appreciate if you could do the following for me when you have a moment:

• open a control port (20023) to c-gate
• execute the following: events e8c0s0
• activate some security PIRs and let me know what you see.

i've seen the following (generated by my ELK/Ness M1):

#e# 20170204-130934.522 702 //SHAC/254/208 3dfc8d80-c4aa-1034-9fa5-fbb6c098d608 [security] exit_delay_started sourceUnit=213
#e# 20170204-130934.712 702 //SHAC/254/208/24 - [security] arm_not_ready sourceUnit=213
#e# 20170204-130934.821 702 //SHAC/254/208 3dfc8d80-c4aa-1034-9fa5-fbb6c098d608 [security] system_arm 1 sourceUnit=213
#e# 20170204-131003.560 702 //SHAC/254/208/13 - [security] zone_sealed sourceUnit=213
#e# 20170204-131457.290 702 //SHAC/254/208 3dfc8d80-c4aa-1034-9fa5-fbb6c098d608 [security] alarm_on sourceUnit=213
#e# 20170204-131458.759 702 //SHAC/254/208/4 - [security] zone_sealed sourceUnit=213
#e# 20170204-132003.899 702 //SHAC/254/208 3dfc8d80-c4aa-1034-9fa5-fbb6c098d608 [security] system_arm 0 sourceUnit=213

i'd expect that you'd see:

#e# 20170204-132003.899 702 //BVC13/254/208/3 3dfc8d80-c4aa-1034-9fa5-fbb6c098d608 [security] zone_unsealed sourceUnit=8

[simonhac]

hi @gbrooker fyi, i plan to make a pull request to address issue #16. i'm concerned my changes will breaking support for your security PIRs. if you could please help me out with the questions above, there's a good chance i can avoid the regression.

[simonhac]

done and dusted!