Spurious Group Broadcasts 2007-11-01T10:56:38+00:00

HOME Forums Input/Output EZIOxx Spurious Group Broadcasts

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • Anonymous
    Post count: 35
    #39802 |

    Hi, guys.

    I have my first 2×4 working well in its intended function, and am confident enough that I just bought my second unit, and will be deploying it in a week or two.

    One oddity remains, though. Every now and then, I get a group broadcast saying that one of the inputs has changed. Within a second or two, I get another saying the input has changed back. I spent quite a bit of time making sure my contacts weren’t really wiggling around or too far apart, etc. Finally, in order to eliminate the contacts or wiring as a possible problems, I removed one of the contacts entirely and just hardwired it “closed.” I still get the group broadcasts for this input.

    If I query the device during the time between the broadcasts (gotta be quick!), I get back a reply, but the bitmask in Cmd2 is all zeros, indicating that all of the inputs are open. A moment or two later, I get the second broadcast, and a query THEN tells me that all the inputs are closed. So I think it’s definitely the 2×4 reporting wrong, not the wiring or contacts. Fortunately, even though the 2×4 thinks everything is open during this brief period, it only broadcasts about the first one.

    When this problem started, it was happening 2-3 times a day, but recently it’s only been about once a week. It’s almost always the first dry contact that reports erroneously.

    Any idea what’s going on?

    Anonymous
    Post count: 15

    Your problem appears to be very similar to the one I encounter with the EZIO8SA and for which I just posted an repply. I had to use the same trick of sacrificing and input to stabilise the other inputs…

    Anonymous
    Post count: 35

    Paul? You there? Any suggestions for me?

    Anonymous
    Post count: 256

    We have not had any luck (or misfortune) to replicate this issue. You are obviously using v1.7 of the firmware, so this is strange… Please supply any other details as to how “sacrificing an input” takes care of the problem.

    Al

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.