Connector Status

Connector Status

There are a couple of ways users can create a program to get the status of a connector and set up alarms.

Options are:

  • One is to create a string point that will have the connector ref.

  • The second option would be to add a connector ref on the equip.

ConnStatus via Custom Point

In this option, a string point per connector would be created. They can be organized under a single equip or nested under their respective equip. It would have a reference to the respective connector so that the status of the connector can be retrieved.

  1. Create new equip to organize the points. We named ours “Connector Status.”

  2. Create a new string point configured as writable and has allowProgram and connStatusPoint marker tags.

    1. We make it writable so that the program can write to it, and the user can view the status, trend it, and use it on a graphic, etc.

    2. allowProgram will allow the point to be used in Logic Builder and allow the program to run on the point level otherwise, it would throw an error that it can't run on the point level.

    3. connStatusPoint is just a unique tag to ensure the program only runs on these connector status points. You can choose to use something else.

  3. On the point, add a property ref tag called connRef and paste the connector's ID to grab the status from. Omit the “id==” portion and save it.

    1. connRef is just a unique tag and can be anything.
      It should look something like this:

  4. Then create the program that runs on the point(s). Below is an example of how it would look like. We are running the program on point and connStatusPoint. Then just hit create.

  5. Then once the program editor is open. On the right menu go to “Add Variables" → “Tag”. The below popup will appear and set it up the same way.

    1. The tag name connStatus is the tag on the connector that we are looking for.

    2. The On field would be set to “Target Ref” because we are looking for connStatus from a property ref tag found on the point. The point is the target and it has a ref. Hence we added "connRef" property tag on the point.

    3. Data type is set to string because the connStatus tag is of a string type.

    4. Is would be read only because we are just reading the value from the connStatus.

  6. Then in the next popup, the variable name can be chosen for that tag (camelCase). In our case, we’ll leave it as is and Ref name would be the connRef.

  7. Then create a new variable that will be used to write to the curVal of the string point. Should be like below.

    1. Tag name = curVal

    2. On = Target

    3. Data type = String

    4. Is = read/write/create

  8. The variable name we can leave as is or change it (camelCase).

  9. That's it, the variables is now ready to be used in the logic. 

Below are screenshots of the program logic that the user can replicate. As well as a copy if they prefer to upload our examples. The example includes a “dis” variable so that the users will be able to know which connector it is in case they have multiple of them. The program is called "connStatusProgramPoint".

BACnet version if needed.

The reason we used to check if it's not ‘ok' and ‘down' is because when it’s down, it doesn't necessarily mean that is bad. It just means that there is nothing keeping it in watch so it’s asleep until viewing the data by opening equip or graphic, or having points historized from that connector etc. This is only for BACnet connectors. If you have a database with BACnet and/or Haystack connectors, we recommend to add the second "Any Connector" version.

 

  Any Connector version. The program is called "connStatusProgramPoint". Runs on "point and allowProgram and connStatusPoint".

ConnStatus via Equip or Site

The goal is just to have a reference of a connector in the database so that it can be visible as an alarm somewhere on the hierarchy tree. It doesn't matter if it's on a site, floor, or equip. Also, only one reference per connector is needed otherwise, there will be multiple alarms of the same connector.

BACnet: To do the below automatically for BACnet connectors since in most cases, each connector is usually one equip. Run this query in Folio: readAll(point and bacnetConnRef).each x=> readById(x->equipRef).diff({connRef:x->bacnetConnRef}).commit()

In cases where a BACnet connector is being used by multiple equips, go through those and remove the extra ones so that you don't get multiple alarms for the same thing.

Haystack: For Haystack connectors, you can add them to the site instead of equip because in most cases, its for an entire site. If, there are multiple for a single site, then it would be best to add them on the a floor or equip level.

  1. First, the user will select an equip they would like to use to get the connector status from. It can be any equip. Then add a connRef property tag to it like below (unless the query above was used).

  2. Then create a program that runs on that equip only or if you have multiple equips for multiple connectors, then run it on those. When creating the program, don't select any points, all you need to do is select "Tags" because we will be using a tag from the connRef property tag that was added. Should look something like below when creating the program. We did it based on "equip and connRef" because we only have one.

  3. Because "Tags" option was selected, the user will be prompted with the below pop up to add additional tags based on available refs on the equip. Since we added 'connRef', it will appear in the drop down for the user to select from. Once selected, the user will see available tags from the connector they can use. In this case, we want the connector status, so we'll select "connStatus" tag and finish creating the program.

  4. From there, the user will now have the variable available to use in logic program. It can be something like if the status is not "ok", then set a boolean variable to true and use that for the alarm etc.

Below are screenshots of the program logic that the user can replicate. As well as a copy if they prefer to upload our examples. The example includes a “dis” variable so that the users will be able to know which connector it is in case they have multiple of them. The program is called "connStatusProgramEquip".

BACnet version if needed. 

The reason we used to check if it's not ‘ok' and ‘down' is because when it’s down, it doesn't necessarily mean that is bad. It just means that there is nothing keeping it in watch so it’s asleep until viewing the data by opening equip or graphic, or having points historized from that connector etc. This is only for BACnet connectors. If you have a database with BACnet and/or Haystack connectors, we recommend to add the second "Any Connector" version.

  

 

 

Any Connector version. The program is called "connStatusProgramEquip". Runs on "(equip or site) and connRef".

Haystack Device Status

There are cases where customers would like to know if certain devices in Niagara are down. In this case, it's difficult to tell since they all come in under one Haystack connector in FIN and it's not necessarily the status of the connector, but the devices in Niagara Network or BACnet Network etc. So to create a program to check if any of those devices are down would be to create a program that runs on a point from each device. That way if the one of those points is down, you'll know which device it is even though the connector is 'ok'. To set this up, follow the below steps.

  1. First the user will tag one point from each device that they know won't change like being renamed or moved etc. The tag in our example is "deviceStatus.” In this case tag the choosen point as "deviceStatus" and "allowProgram".

  2. Then create the program to run on the those points. It should look like something below.

  3. Then create a new variable from the "Add Variable" from the right menu. We want to add the curStatus of the point. Then we use that in logic to trigger the alarm based on the status of the point.
    Tag name = curStatus
    On = Target
    Data type = String
    Is = Read Only

The example includes a “dis” variable so that the users will be able to know which connector it is in case they have multiple of them. The program is called "connStatusProgramPoint".

Below are screenshots of the program logic that the user can replicate. As well as a copy if they prefer to upload our examples. It also includes the dis, equipNavName, siteNavName, and navName variables so that the users will be able to know which site, floor, equip, and point it is in case they have multiple of them. The program is called "deviceStatusProgram".

  

 

 

So all the user has to do if they upload the program is make sure the point is tagged correctly as mentioned above and it should work. Remember, only do one point per device.