GSD Tutorial

[los93sol]

I've got an alarm panel I'd love to add support for, I have spent a good amount of time reading the wiki, forum posts, etc. about the GSD and how to add devices, but I'm still struggling with some pieces of it.  How do I know what the commands available actually do?  How do I know what should be set and how they should be set?  When should Ruby code be used to support a device.

My scenario is this, I have a Vista-15P alarm panel, it is a Honeywell panel that does not have RS-232 or Ethernet natively on it.  I had to purchase a VistaICM module with connects to the panel as a control pad and then interfaces to the network via a web interface.  I know it should be quite trivial to set this up since I can control my panel by just going to specific sets of URLs.  For example to arm my panel I go sequentially just hit:

http://192.168.80.3/padID=1
http://192.168.80.3/padID=2
http://192.168.80.3/padID=3
http://192.168.80.3/padID=4
http://192.168.80.3/padID=1

and to disarm I could sequentially hit:
http://192.168.80.3/padID=1
http://192.168.80.3/padID=2
http://192.168.80.3/padID=3
http://192.168.80.3/padID=4
http://192.168.80.3/padID=2

This would at least give me some basic functionality of the unit, but I have no clue how to go about setting this up as a GSD.  I had a look over the existing device templates, but I still have not been able to get my head around how to setup something like this.  Any help would be greatly appreciated.

If I could even just set it up so that the buttons in the security screen would send these commands to my panel that would be great, can anyone elaborate on how the Destiny panel's device works?  Does it work as if LMCE were acting as you panel or just the buttons?

[hari]

look at the Apex destiny 6100 template, it is pretty complete.

best regards,
Hari

[los93sol]

I am aware of the Destiny template, but I am having trouble understanding the template.  I guess the resource I'm looking for is a breakdown of the individual pieces contained in a GSD.  I've been searching for a walkthrough of setting up a GSD with the parameters explained so I can wrap my head around the whole concept.  I'm just not understanding what each parameter does or how you determine what they should be set to.

[tschak909]

Well, just start asking questions, no matter how small, we'll try to answer them as best we can.

-Thom

[colinjones]

I can give a very basic explanation based on my very limited understanding!

Essentially, GSD is a translator. GSD has lots of "commands" to do various things with media, HA, etc - you can see these inside GSD templates referenced by numbers like #193/192 for power on/off. Or #89/90 for volume up/down. (from memory!)

When the native DCE protocol is used by a remote device to send a DCE message either explicitly to your GSD device number, or implicitly to your GSD device by virtue of it being: in a group of devices, a category of devices or somewhere along a audio/video pipe - this message is interpreted by the GSD binary code.

That code then looks at the associated device data in the database to determine whether the necessary GSD "commands" are implemented by the device to complete the task that the DCE message requested. In the device configuration data you will see these GSD "commands" and you can add/remove whichever ones you want your GSD device to be able to handle. Each of these "commands" then have a text field in which you can place Ruby code.

So effectively the GSD binary is translating DCE messages into the correct Ruby code required to perform the task. Of course you can do normal programmatic stuff in Ruby, but ultimately most device templates then have a Ruby command to send/receive text strings to a serial port. So you can use the Ruby code to form the appropriate text string to send to the physical device you are controlling based on the protocol that it accepts.

So if LMCE decides that an MD has been idle for a period and wants to powersave, it will send a power off DCE message to the audio and video pipes configured for that MD's entertainment area. If you are controlling, say, a TV and Amp from that MD, these devices will have an audio and video pipe from the MD to them. So the DCE message gets routed to the 2 GSD devices controlling your Amp and TV. These two GSD devices will determine whether command #193 is implemented for each device. And if so, will execute the Ruby code associated with those command numbers. That Ruby code can then send the correct power off string to each of the physical devices.

I wrote this with serial in mind, but the principle holds for IR as well. I'm sure the other guys will correct anything I got wrong.

[colinjones]

BTW, the beauty of this approach is that LMCE itself doesn't have to know what devices are attached to an MD, which commands they implement, nor how to communicate with them.

When the time comes to power off the Entertainment Area, it just sends the appropriate DCE message. If there are any TVs, Amps, etc setup on pipes in that EA, the message automatically gets sent to all of them (if there aren't any, then the message just disappears and nothing happens). Then GSD determines whether the necessary GSD command(s) are implemented for that device to perform the task and executes the associated code (if they aren't then it just ignores the DCE message). Then the code executes and forms the correct string to send to the physical devices.

All of this is transparent to LMCE, so you can implement just about whatever you want!

[los93sol]

Okay, I'm working on this now...pretty much posting so that I have notes to reflect back to later at this point, but I have a set of variables and a set of commands that the panel can accept so I need to now figure out how to read the variables and pipe them back to LMCE to see the status of my security system, I also need to sort how to send the commands to the panel from LMCE so that I can control my panel.

Commands:
0: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=0&~cgi.cmdl=1&auth=0
1: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=1&~cgi.cmdl=1&auth=0
2: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=2&~cgi.cmdl=1&auth=0
3: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=3&~cgi.cmdl=1&auth=0
4: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=4&~cgi.cmdl=1&auth=0
5: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=5&~cgi.cmdl=1&auth=0
6: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=6&~cgi.cmdl=1&auth=0
7: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=7&~cgi.cmdl=1&auth=0
8: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=8&~cgi.cmdl=1&auth=0
9: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=9&~cgi.cmdl=1&auth=0
1 and 3: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=1 and 3&~cgi.cmdl=1&auth=0
F1: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=F1&~cgi.cmdl=1&auth=0
F2: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=F2&~cgi.cmdl=1&auth=0
F3: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=F3&~cgi.cmdl=1&auth=0
F4: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=F4&~cgi.cmdl=1&auth=0
Pound: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=Pound&~cgi.cmdl=1&auth=0
Pound and 3: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=Pound and 3&~cgi.cmdl=1&auth=0
Star: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=Star&~cgi.cmdl=1&auth=0
Star and 1: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=Star and 1&~cgi.cmdl=1&auth=0
Star and Pound: http://192.168.80.114/diag?~cgi.diag=1&~cgi.cmd=Star and Pound&~cgi.cmdl=1&auth=0

Variables:
Alarm=0
AlarmEvent=0
ArmAway=0
ArmInstant=0
ArmStatus=0
ArmStay=0
BlankDHDL=3
Bypass=0
Check=0
Chime=1
DevAddr=18
Fire=0
FireEvent=0
HighVolAlarm=0
HighVolFire=0
ID=Honeywell Vista 1.1
LowBat=0
LowBatEvent=0
Power=1
Program=0
Ready=1
ZS=
Zone=08
ZoneHex=8
ZoneKey=ZS.09
ZoneKeyTemp=3
ZoneName=
_param1=Disarmed
_params=1
address=
address1=editedout@gmail.com
address2=
address3=
alpha=
away_delay=0
body=
button1=assignable value
button2=assignable value
button3=assignable value
button4=assignable value
display= DISARMED CHIME
emailAlarm=on
emailArm=on
emailDisarm=on
emailFire=on
emailLowBat=on
emailPower=on
emailadd=editedout@gmail.com
id=Honeywell Vista
if=Security,gridw1x4[Function,F1{Away},F2{Stay},F3{Monitor},F4{Panic}],Grid3x4[Keypad,1{1Off},2{2Away},3{3Stay},4{4Max},5{5Test},6{6Bypass},7{7Instant},8{8Code},9{9Chime},*{*Ready},0{0},#{#}]
message=(0.0.0)_T_Vista-15P:Disarmed
newDevAddr=18
sentArm=0
sentArmAway=0
sentArmStay=0
sentDisarmed=1
sentPower=0
star_send_enabled=on
stay_delay=0
subject=Security Alert
trigger_delay=15s
txt_1= DISARMED CHIME
txt_2=  Ready
txt_3=to Arm 
~alpha_pos=2
~hour=7
~init=1
~mday= 9
~meridiem=PM
~min=20
~mon=Dec
~name=Vista-15P
~wday=Tue
~year=2008

[los93sol]

Okay, I've decided to just get the panel to where I can either arm or disarm until I understand what is happening with GSD devices...I'm looking over the Apex Destiny 6100 template and the Panasonic IP camera templates now, but I have some immediate questions.  I see the Destiny template is for use over serial so I'll have to apply some lessons from both templates.  It looks to me like LMCE provides it's own commands which can be added to the template, but I'm not understanding what they actually are or how they are used.  I also am seeing that the device data looks to be commands that are specifically for my template and will only be used in my template.  This bit I guess makes a little more sense, but I cannot see in the Panasonic IP Camera where the video feed URL is directed to LMCE in the device data, only a path which is in the commands instead of the device data so that is unexpected.  Can someone provide some insight into what and how these items are used in device templates please?

[los93sol]

bump