Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Writing to fields in Err state
Okay, so I'm fixing my drivers to either provide values or put fields in err state before connect returns.  One thing I have noticed is that DriverBase blocks field writes before calling the driver implementation when the field is in err state.

CQCKit, CQCDriver_DriverBase.cpp.7089, Failed/Not Ready, Error: 2017/0/0

Seems to me that in some cases, the field may not have a value right now, but it should still be writeable.  In my case I asked the lighting controller the state of the light and it said "I dunno", but if I wriet "turn it off", the write will succeed (sometimes), and the field will get a value of "off".

Currently I don't get the chance to push a write at a recalcitrant light because DriverBase eats the attempt before it gets to me.

Can a WriteOnly field be in err state?  I guess I have a Read/Write field and I want it to be in ReadErr/WriteOk state.  

Hmmm.  -- Bob
Write only fields are skipped when you call SetAllErrStates(). They don't really have an concept of being in error. If it's readable, it will get marked. And, if marked, it can't be written to by clients. The driver can do that, but not clients. The reason being that the driver doesn't know if this is a change of value because it has no existing value to compare it to.

So, if you want it to be writable, you have to put some value in it. It's a tough thing to get right, since nothing we do will ultimately be correct for everyone. So it just leans towards, don't do anything unless you are sure. And it assumes that if the thing you are trying to write to was happy enough to write to, we'd have a value for it.

I can understand how that might be an issue for something like Z-Wave, for instance. In that case, the msg written isn't sent right then usually (because it's in error because it's battery powered and we haven't heard from it yet.) The msg gets queued up and sent later. So that sort of makes sense that it should be writable before it has a value.

Not sure how best to handle such things.
Dean Roddey
Explorans limites defectum
If DriverBase doesn't have an existing value, then pass all writes to the driver (i.e. BoolFldChanged) just as you would for WriteOnly fields.  The driver can then handle the writes on a case by case basis.

Of course DriverBase has been blocking these calls for quite a while, so it is a potentially breaking change.  Pretty narrow corner case though, and most drivers probably return error ultimately anyway.  

Seems unlikely to do any great damage, but who knows.
If I did it, it would likely need to be such that the driver has to request it on a given field. There is already a 'write always' but that's to tell the base class to call the driver even if the value written is the same as the current value. So we'd need something like 'error write OK' or something.
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  SetAllErrStates messes up $ fields rbroders 3 1,215 01-26-2019, 03:24 PM
Last Post: Dean Roddey
  An error occured while loading persistent state SomeWhatLost 3 2,272 03-01-2009, 05:56 AM
Last Post: SomeWhatLost
  Bind a checkbox to an event's state? SamVimes2 1 1,985 02-13-2009, 06:39 PM
Last Post: Dean Roddey
  anyone fancy writing a driver for my eva8000 willplaice 0 2,894 05-20-2008, 05:29 AM
Last Post: willplaice

Forum Jump:

Users browsing this thread: 1 Guest(s)