ECS-L Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ECS] Creating ECS interface to my Access Control System
Kevin Trainor
Mon, 30 Oct 2000 17:32:21 -0600
Mon, 30 Oct 2000 17:32:21 -0600
Brian:

You were right.  I was running an older version of ECS that had a similarly-named but
different option.  I have installed the newest version and I am hoping for the best.
 Thanks for your help.

Kevin
  ----- Original Message ----- 
  From: Brian McGinnis 
  To: ecs-list@netbloc.com 
  Sent: Monday, October 30, 2000 10:19 AM
  Subject: Re: [ECS] Creating ECS interface to my Access Control System


  Kevin, 
    Could it be that this is something Mark has added recently?  I think I'm running
version 4.4.010 if I remember correctly.  Double check HLT:Probe Temp Text and make
sure it is defined as a "text" item.

  Also, I suppose you might be able to use the T1<-Stt operator to set it to another
text item that is blank.

  I'd be curious to know if in your copy of the online help, under "Text-Type" if it
shows "Reset" as one of the options.  It does in mine.

  HTH,
  Brian
     ----- Original Message ----- 
    From: Kevin Trainor 
    To: ecs-list@netbloc.com 
    Sent: Monday, October 30, 2000 8:00 AM
    Subject: Re: [ECS] Creating ECS interface to my Access Control System


    Brian:

    I have been working on this project using your code as a guide.  I am stuck on what
will probably prove to be a simple problem.  When I try to re-initialize the text item
that I am building, I don't seem to be able to set it to a value of "reset".  "Reset"
 is not one of the menu choices and I get an error when I type in "reset".  I based
my code on the following line from your code:

    Then HLT:Probe Temp Text     Set  Reset

    Is it possible that I have defined my text item as the wrong type?  I thought that
I had followed your example faithfully when I defined the item.

    Do you have any suggestions as to where I might be going wrong?

    Kevin 
      ----- Original Message ----- 
      From: Brian McGinnis 
      To: ecs-list@netbloc.com 
      Sent: Thursday, October 26, 2000 11:16 AM
      Subject: Re: [ECS] Creating ECS interface to my Access Control System


      <I have sent this msg in HTML format to hopefully preserve the formatting.  I
apologize in advance if this causes problems for anyone.>

      Hi Kevin,
      I decided to post this directly to the list in case anyone else cares.  This is
one 
      example about using the Serial-Byte item type to poll devices not directly supported
by 
      ECS.

      First of all, everything is received a byte (character) at a time.  At first this
may 
      seem like it would make the event writing more difficult, but I think you'll find

      that's not really the case.  At any rate, most any programming language that you
would 
      use would be set up the same way.  Note: You can use the SEND->COM{d} state on
a text 
      item to send an entire string of characters out a COM port.  This can be useful
for 
      delivering lengthy commands to the device.

      This sample sends a one-byte command to a serial device known as a "Hot Little

      Therm" that has temp sensors attached to it.  The device responds with a list
of temp 
      sensor Ids and the temperature.  For example, if I have two temp sensors attached
to 
      the first HLT device, then:

      I send: "16"  (no quotes) by setting  HLT:Hot Little Therm to 16

      Device responds:

      V93-7200<CR><LF>                   ;Firmware revision and serial number
      S1<CR><LF>                         ;Digital Input level
      T10460247000000d9 +019.8<CR><LF>   ;Probe #1 ID and temp
      T10fdd94600000087 -005.5<CR><LF>   ;Probe #2 ID and temp
      Z<CR><LF>                          ;End of list

      16 is the command that tells the HLT to send back all the Ids and their readings

      attached to the first HLT device.

      ECS's job then, will be to parse this returned data for the probe id so that it
can be 
      matched with an actual ECS item, along with it's temp value.

      Let's take a look at the items involved:

      ;This is the actual device defined as a Serial-Byte item
      Item:HLT:Hot Little Therm Type:Serial-Byte  Acc:User/Owner
       Initial State:(none)     Backup:No
       Serial Port  :COM1
       Baud Rate    :1200
       Parity       :None
       Stop Bits    :1

      ;This text item will hold the returned temp value for probe 1
      Item:HLT:Probe 1  Type:Text   Acc:User/Owner
       Initial State:(none)     Backup:No
       Text         :

      ;This text item will hold the returned temp value for probe 2
      Item:HLT:Probe 2  Type:Text   Acc:User/Owner
       Initial State:(none)     Backup:No
       Text         :

      ;The text item holds the ID of probe 1.  Each temp sensor has a
      ;unique ID.  We take advantage of this fact to make sure we're
      ;matching the right temp value with the right probe
      Item:HLT:Probe 1 ID  Type:Text   Acc:User/Maint
       Initial State:(none)     Backup:No
       Text         :T10460247000000d9

      ;As above, but the ID of probe 2
      Item:HLT:Probe 2 ID  Type:Text   Acc:User/Maint
       Initial State:(none)     Backup:No
       Text         :T10fdd94600000087

      ;This character item holds the byte just read from the Serial-Byte
      ;device
      Item:HLT:Byte Read  Type:Character   Acc:User/Maint
       Initial State:(none)     Backup:No

      ;This text item holds the probe id that is currently being read.
      ;It is built one character at a time.
      Item:HLT:Probe ID Text  Type:Text   Acc:User/Maint
       Initial State:(none)     Backup:No
       Text         :

      ;This number item keeps track of what type of data is coming in from
      ;the device: 1 means it is receiving a probe ID, 2 means that it is
      ;receiving a temperature, and 3 means we have completed reading 
      ;one probe id and temperature.
      Item:HLT:Read Mode  Type:Number   Acc:User/Maint
       Initial State:(none)     Backup:No

      ;This text item holds the temperature currently coming in from
      ;the device.  It is built one character at a time.
      Item:HLT:Probe Temp Text Type:Text   Acc:User/Maint
       Initial State:(none)     Backup:No
       Text         :


      OK, here is the event that actually reads the probe Ids and temps coming in from
the device:

      Event: Read HLT   Called ?:No
       ;
       ; Read Hot Little Therm Device
       ;
       ;Fetch character, if any, from the device.
       Do HLT:Byte Read  Set  HLT:Hot Little Therm
       ;Check it for a value. Do not test the Serial-Byte item directly,
       ;load it into another item as we've done here first, then
       ;test that.
       ;If there is no activity on the port, then exit the event.
       If HLT:Byte Read  Is  None
       Then Event-Exit  Set  True
       ;
       ;If there is activity, then start a loop to process all characters
       ;sitting in the buffer. By setting up this looping structure, we
       ;can read more than one character from the device per event pass.
       WHILE HLT:Byte Read  Is Not  None
       ;
       ; If text coming in begins with a T, we know it is going to
       ; be the Probe ID, so clear the text item in preparation and
       ; set the mode to indicate probe ID data is coming.
       If HLT:Byte Read          Is  T
       Then HLT:Probe ID Text    Set  Reset
       Then HLT:Read Mode        Set  1
       ;
       ; On the other hand, if we find a space in the text,
      ; it always precedes a temp value, so clear the text
      ; item in preparation and set the mode to indicate
      ; temperature data in coming.
       If HLT:Byte Read             Is  <Space>
       Then HLT:Probe Temp Text     Set  Reset
       Then HLT:Read Mode           Set  2
       ;
       ; If we find a <CR> and the mode is 2 (temp value),
      ; then we know we're done reading this probe's data.
      ; It's time to evaluate what we've got.
       If HLT:Byte Read      Is  <CR>
       And HLT:Read Mode     Is  2
       Then HLT:Read Mode    Set  3
       ;
       ; Build up the 2 strings according to what mode we're in
       ; character by character.
       If HLT:Read Mode       Is  1
       Then HLT:Probe ID Text T1/A<-Stt HLT:Byte Read
       ;
       If HLT:Read Mode   Is  2
       And HLT:Byte Read   Is Not <Space>
       Then HLT:Probe Temp Text T1/A<-Stt HLT:Byte Read
       ;
       ; Assign temperature value to correct probe.
       BEGINIF HLT:Read Mode  Is Now  3
       If HLT:Probe ID Text   Is/T1   HLT:Probe 1 ID
       Then HLT:Probe 1       T1<-T1  HLT:Probe Temp Text
       If HLT:Probe ID Text   Is/T1   HLT:Probe 2 ID
       Then HLT:Probe 2       T1<-T1  HLT:Probe Temp Text
       ENDIF
       ;
       ; Check for another byte in the buffer now, without waiting
       ; for another event pass.  This speeds up reading from the
       ; device dramatically.
       Do HLT:Byte Read  Set  HLT:Hot Little Therm
       ; Loop back to the beginning and test the HLT:Byte Read item
       ; for data.
       ENDWHILE
       End


      So, sending the command to the device is easy, whenever you feel the need for
updated 
      temp info, just:

      DO HLT:Hot Little Therm SET 16

      The event will take care of the rest.

      Some additional things to think about:

      The serial data may not arrive at the port in one big chunk.  Don't write an event
that sets up a loop once data is received at the port and considers all of the data
to be present in that loop.  A looping structure is great for processing all of the
data sitting at the port, but don't count on all of it being there at once.  The above
event is written to handle this.  It reads data in a looping structure as long as it's
there, but doesn't make any decisions about what to do with it until it sees the appropriate
terminations.  This could take one event pass, 
      or many.

      I hope this helps get you started.
      Brian




Brian:
 
You were right.  I was running an older version of ECS that had a similarly-named but different option.  I have installed the newest version and I am hoping for the best.  Thanks for your help.
 
Kevin
----- Original Message -----
From: Brian McGinnis
To: ecs-list@netbloc.com
Sent: Monday, October 30, 2000 10:19 AM
Subject: Re: [ECS] Creating ECS interface to my Access Control System

Kevin,
  Could it be that this is something Mark has added recently?  I think I'm running version 4.4.010 if I remember correctly.  Double check HLT:Probe Temp Text and make sure it is defined as a "text" item.
 
Also, I suppose you might be able to use the T1<-Stt operator to set it to another text item that is blank.
 
I'd be curious to know if in your copy of the online help, under "Text-Type" if it shows "Reset" as one of the options.  It does in mine.
 
HTH,
Brian
 ----- Original Message -----
From: Kevin Trainor
To: ecs-list@netbloc.com
Sent: Monday, October 30, 2000 8:00 AM
Subject: Re: [ECS] Creating ECS interface to my Access Control System

Brian:
 
I have been working on this project using your code as a guide.  I am stuck on what will probably prove to be a simple problem.  When I try to re-initialize the text item that I am building, I don't seem to be able to set it to a value of "reset".  "Reset"  is not one of the menu choices and I get an error when I type in "reset".  I based my code on the following line from your code:
 
Then HLT:Probe Temp Text     Set  Reset
 
Is it possible that I have defined my text item as the wrong type?  I thought that I had followed your example faithfully when I defined the item.
 
Do you have any suggestions as to where I might be going wrong?
 
Kevin 
----- Original Message -----
From: Brian McGinnis
To: ecs-list@netbloc.com
Sent: Thursday, October 26, 2000 11:16 AM
Subject: Re: [ECS] Creating ECS interface to my Access Control System

<I have sent this msg in HTML format to hopefully preserve the formatting.  I apologize in advance if this causes problems for anyone.>
 
Hi Kevin,
I decided to post this directly to the list in case anyone else cares.  This is one
example about using the Serial-Byte item type to poll devices not directly supported by
ECS.
 
First of all, everything is received a byte (character) at a time.  At first this may
seem like it would make the event writing more difficult, but I think you'll find
that's not really the case.  At any rate, most any programming language that you would
use would be set up the same way.  Note: You can use the SEND->COM{d} state on a text
item to send an entire string of characters out a COM port.  This can be useful for
delivering lengthy commands to the device.
 
This sample sends a one-byte command to a serial device known as a "Hot Little
Therm" that has temp sensors attached to it.  The device responds with a list of temp
sensor Ids and the temperature.  For example, if I have two temp sensors attached to
the first HLT device, then:
 
I send: "16"  (no quotes) by setting  HLT:Hot Little Therm to 16
 
Device responds:
 
V93-7200<CR><LF>                   ;Firmware revision and serial number
S1<CR><LF>                         ;Digital Input level
T10460247000000d9 +019.8<CR><LF>   ;Probe #1 ID and temp
T10fdd94600000087 -005.5<CR><LF>   ;Probe #2 ID and temp
Z<CR><LF>                          ;End of list
 
16 is the command that tells the HLT to send back all the Ids and their readings
attached to the first HLT device.
 
ECS's job then, will be to parse this returned data for the probe id so that it can be
matched with an actual ECS item, along with it's temp value.
 
Let's take a look at the items involved:
 
;This is the actual device defined as a Serial-Byte item
Item:HLT:Hot Little Therm Type:Serial-Byte  Acc:User/Owner
 Initial State:(none)     Backup:No
 Serial Port  :COM1
 Baud Rate    :1200
 Parity       :None
 Stop Bits    :1
 
;This text item will hold the returned temp value for probe 1
Item:HLT:Probe 1  Type:Text   Acc:User/Owner
 Initial State:(none)     Backup:No
 Text         :
 
;This text item will hold the returned temp value for probe 2
Item:HLT:Probe 2  Type:Text   Acc:User/Owner
 Initial State:(none)     Backup:No
 Text         :
 
;The text item holds the ID of probe 1.  Each temp sensor has a
;unique ID.  We take advantage of this fact to make sure we're
;matching the right temp value with the right probe
Item:HLT:Probe 1 ID  Type:Text   Acc:User/Maint
 Initial State:(none)     Backup:No
 Text         :T10460247000000d9
 
;As above, but the ID of probe 2
Item:HLT:Probe 2 ID  Type:Text   Acc:User/Maint
 Initial State:(none)     Backup:No
 Text         :T10fdd94600000087
 
;This character item holds the byte just read from the Serial-Byte
;device
Item:HLT:Byte Read  Type:Character   Acc:User/Maint
 Initial State:(none)     Backup:No
 
;This text item holds the probe id that is currently being read.
;It is built one character at a time.
Item:HLT:Probe ID Text  Type:Text   Acc:User/Maint
 Initial State:(none)     Backup:No
 Text         :
 
;This number item keeps track of what type of data is coming in from
;the device: 1 means it is receiving a probe ID, 2 means that it is
;receiving a temperature, and 3 means we have completed reading
;one probe id and temperature.
Item:HLT:Read Mode  Type:Number   Acc:User/Maint
 Initial State:(none)     Backup:No
 
;This text item holds the temperature currently coming in from
;the device.  It is built one character at a time.
Item:HLT:Probe Temp Text Type:Text   Acc:User/Maint
 Initial State:(none)     Backup:No
 Text         :
 

OK, here is the event that actually reads the probe Ids and temps coming in from the device:
 
Event: Read HLT   Called ?:No
 ;
 ; Read Hot Little Therm Device
 ;
 ;Fetch character, if any, from the device.
 Do HLT:Byte Read  Set  HLT:Hot Little Therm
 ;Check it for a value. Do not test the Serial-Byte item directly,
 ;load it into another item as we've done here first, then
 ;test that.
 ;If there is no activity on the port, then exit the event.
 If HLT:Byte Read  Is  None
 Then Event-Exit  Set  True
 ;
 ;If there is activity, then start a loop to process all characters
 ;sitting in the buffer. By setting up this looping structure, we
 ;can read more than one character from the device per event pass.
 WHILE HLT:Byte Read  Is Not  None
 ;
 ; If text coming in begins with a T, we know it is going to
 ; be the Probe ID, so clear the text item in preparation and
 ; set the mode to indicate probe ID data is coming.
 If HLT:Byte Read          Is  T
 Then HLT:Probe ID Text    Set  Reset
 Then HLT:Read Mode        Set  1
 ;
 ; On the other hand, if we find a space in the text,
; it always precedes a temp value, so clear the text
; item in preparation and set the mode to indicate
; temperature data in coming.
 If HLT:Byte Read             Is  <Space>
 Then HLT:Probe Temp Text     Set  Reset
 Then HLT:Read Mode           Set  2
 ;
 ; If we find a <CR> and the mode is 2 (temp value),
; then we know we're done reading this probe's data.
; It's time to evaluate what we've got.
 If HLT:Byte Read      Is  <CR>
 And HLT:Read Mode     Is  2
 Then HLT:Read Mode    Set  3
 ;
 ; Build up the 2 strings according to what mode we're in
 ; character by character.
 If HLT:Read Mode       Is  1
 Then HLT:Probe ID Text T1/A<-Stt HLT:Byte Read
 ;
 If HLT:Read Mode   Is  2
 And HLT:Byte Read   Is Not <Space>
 Then HLT:Probe Temp Text T1/A<-Stt HLT:Byte Read
 ;
 ; Assign temperature value to correct probe.
 BEGINIF HLT:Read Mode  Is Now  3
 If HLT:Probe ID Text   Is/T1   HLT:Probe 1 ID
 Then HLT:Probe 1       T1<-T1  HLT:Probe Temp Text
 If HLT:Probe ID Text   Is/T1   HLT:Probe 2 ID
 Then HLT:Probe 2       T1<-T1  HLT:Probe Temp Text
 ENDIF
 ;
 ; Check for another byte in the buffer now, without waiting
 ; for another event pass.  This speeds up reading from the
 ; device dramatically.
 Do HLT:Byte Read  Set  HLT:Hot Little Therm
 ; Loop back to the beginning and test the HLT:Byte Read item
 ; for data.
 ENDWHILE
 End
 

So, sending the command to the device is easy, whenever you feel the need for updated
temp info, just:
 
DO HLT:Hot Little Therm SET 16
 
The event will take care of the rest.
 
Some additional things to think about:
 
The serial data may not arrive at the port in one big chunk.  Don't write an event that sets up a loop once data is received at the port and considers all of the data to be present in that loop.  A looping structure is great for processing all of the data sitting at the port, but don't count on all of it being there at once.  The above event is written to handle this.  It reads data in a looping structure as long as it's there, but doesn't make any decisions about what to do with it until it sees the appropriate terminations.  This could take one event pass,
or many.
 
I hope this helps get you started…
Brian
 
 

  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.