#886 nHaystack v3.0.1 / WatchSub and poll when curStatus=fault

Tyler B. Long Wed 17 Feb

In Niagara there is a point configured which has an alarm extension set to place the point's value in its fault state. When making either a WatchSub or WatchPoll request against this point, the curStatus=fault as expected however both the zinc and json responses come back with a null value as shown below:

The json reponse:

{
    "meta": {
        "ver": "2.0",
        "watchId": "143da86f-7fa7-4681-9be0-c2c0745249d9",
        "lease": "n:10000 ms"
    },
    "cols": [
        {
            "name": "curStatus"
        },
        {
            "name": "curVal"
        },
        {
            "name": "id"
        }
    ],
    "rows": [
        {
            "curStatus": "ok",
            "curVal": true,
            "id": "r:C.Examples.AHU~2d01.FanStatus"
        },
        {
            "curStatus": "fault",
            "id": "r:C.Examples.AHU~2d01.SupplyTemp"
        }
    ]
}

The zinc response:

ver:"3.0" watchId:"3b9e058b-5830-4557-bc73-d7726f9b968f" lease:10000ms
curStatus,curVal,id
"ok",T,@C.Examples.AHU~2d01.FanStatus
"fault",,@C.Examples.AHU~2d01.SupplyTemp

Is it expected that nHaystack should return a null curVal when curStatus is in fault? If this is expected behavior what would be the reasoning for not returning the value when the point is in fault?

Edit: Posted this info on the github repo below in case these questions turned out to be more of a nHaystack issue rather than generic haystack behavior: https://github.com/ci-richard-mcelhinney/nhaystack/issues/9

Brian Frank Wed 17 Feb

By definition curVal is only available if curStatus is ok or stale. So that seems like the correct behavior to me

Tyler B. Long Wed 17 Feb

Thanks for confirming. The updated curStatus page makes it more clear when curVal is not to be expected.

Login or Signup to reply.