search

otcshare / automotive-message-broker

Other
48 stars 48 forks source link

Version bump and Value Quality #58

Closed tripzero closed 9 years ago

tripzero commented 9 years ago

This should address issue #51.

tripzero commented 9 years ago

I'll look into that suggestion. What would the ability to accept "null" provide?

petr-nechaev commented 9 years ago

In theory, Value, Time and Quality should be set at once, because they correspond to one moment of time when something happened to the property. VTQs are immutable in the sense that you can't update only, let's say, "Quality" part without affecting other. If you see that vehicle speed is 30 mph then you also know that Quality is "good" and Time = Now. If you see that speedometer is broken: needle is pointing to 0 but you're driving on a highway at a good speed, then you know that that Value = 0, Quality = "bad", Time = "now".

So, if the user (plugin developer) calls setValue(val) , they set mValue = val, valueQuality = Good, timestamp = current. If they call setValue(val, quality) they set mValue=val, valueQuality = quality, timestamp = current. And only if they call setValue(val, quality, time) they want to set all properties manually.

But, in practice, it makes sense to keep "last known good value" in case of communication loss, when only quality is known, with the hope that communication will be restored quickly. This would be setValue(amb::Quality::BadTimeout) or setValue(NULL, amb::Quality::BadTimeout).

Typically, it is better than setting default value with setValue(0, amb::Quality::BadTimeout) because the latter causes "flickering" in digital displays, when "000" appear on intermittent communication loss.

P.S. I'd also make AbstractPropertyType thread-safe so there is no chance of seeing inconsistent mValue, timestamp and valueQuality. Sorry, I don't have time to implement this myself at the moment.

tripzero commented 9 years ago

I will overload setValue as you suggested.