Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 2.5 Beta Thread
I'm getting numerous false triggers from a NewFldValueEquals event too, but my field is one from the Omni driver which shows multiple lost comm errors, so I'm not certain if the error is really in the trigger or the fact that it disconnects momentarily.
Hmmm...my Ocelot driver has been quite flakey, with a decent number of disconnects too. I just recycled CQC, so I don't have any lost comm or lost connect counts...but there's a high possibility the Ocelot may have disconnected around the time I got the event.
zpollock Wrote:I'm getting numerous false triggers from a NewFldValueEquals event too, but my field is one from the Omni driver which shows multiple lost comm errors, so I'm not certain if the error is really in the trigger or the fact that it disconnects momentarily.

Are you using the new TCP/IP one or the old UDP driver?
Dean Roddey
Explorans limites defectum
beelzerob Wrote:Hmmm...my Ocelot driver has been quite flakey, with a decent number of disconnects too. I just recycled CQC, so I don't have any lost comm or lost connect counts...but there's a high possibility the Ocelot may have disconnected around the time I got the event.

I'm not really sure how would be best to deal with such things. If a driver cycles, the initial value of any fields will be the obvious stuff, False for boolean, empty string for strings, the first enumerated value for enumerated strings, and so forth. If, in the process of connecting, those values change, an even trigger will go out.

I think that's appropriate, but it could cause something to re-trigger after it's already been triggered, i.e. it was in True state, the driver disconnected, the initial default value is False, then while populating the fields it goes True again.

Maybe event trigger propogation should be disabled until after the driver connects and only sent out for changes that occur after initial field propogation?
Dean Roddey
Explorans limites defectum
Dean Roddey Wrote:Are you using the new TCP/IP one or the old UDP driver?

The new TCP/IP one.

I like your suggestion above that perhaps event triggers shouldn't fire on the initial reconnect. Or, perhaps that could be a selectable option. There are some cases where you might wish for things to fire when the system comes back online, but it it seems that the potential for misfires from unintended disconnects would be far greater than intentional triggers on reboot, etc.

Ideally, it would be nice if the system knew how long the driver had been offline and there was a threshold. In other words, if it was a brief disconnect of a few seconds, then don't fire. If the driver was offline for a longer period, then respond appropriately.
Hmmm...ya, I had noticed this same thing happen with my datanab device/driver. I was downstairs working on stuff, and so I unplugged the datanab to move it around and then plugged it back in. After a couple minutes, the wife comes down the stairs asking why the PC is saying there's a fire in the garage. :oops: I had figured it was some flaw in the datanab driver.

Isn't the goal of the drivers that they have fully valid field values before transitioning to connect, though? If they did that, then this wouldn't be an issue, would it?

I'm not sure if the ocelot does that, but I'm pretty sure the datanab gets all values before going to connect.
They do that. But they also don't prevent field value transitions from causing triggers during the connect period when they are setting up the initial field values, if the field transitions to a value that is set up to cause a trigger to be sent out.

So the question is, should they not do that? Sounds like I guess they shouldn't. However, that would mean that, if the device came up with a value in a field that would have normally caused a trigger, that won't happen anymore, since it won't have transitioned to that value, it will have just started with that value.

So it could cut both ways.
Dean Roddey
Explorans limites defectum
But anyway, this is no longer a beta discussion. I'll start a thread on this in the support area for more broad discussion.
Dean Roddey
Explorans limites defectum
I'm going to close this thread off since 3.0 is now released. Issues can be moved to the support section until such time as we get back into a beta phase again.
Dean Roddey
Explorans limites defectum


Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 41,755 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 7,324 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,300 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,910 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 87,644 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,804 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 197,132 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,502 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 489,144 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,314 11-01-2016, 10:32 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)