4billl wrote:Dave - I have very straightforward requirements for my use of you OW Server Plugin: Reliable, analog readings from standard part numbers or Embedded Data Systems current part numbers.
If I have to rebuild my list (once more), so be it.
BUT - I am a relatively new OW user so I may not be as invested in my particular device assignments as some of your other users may be already.
AND I may be having simpler demands: As OW is slow to respond to inputs (compared to EasyDAQ or Phidgets), I am not using it for those sensors.
My setup was originally based on Phdgets - analog, digital in & digital out.
But over the years, I have been unable to depend on Phidgets reliability. No matter how I have auto rebooted, auto-re-established monitoring, or even manually recycled power, the Phidget interface randomly stops reporting. So after thousands of $$ and hundreds of hours, it's time to move on.
I have replaced all the digital inputs and outputs of my 6 SBC boards with EasyDAQ connections. They have been reliable and never needed to be reset.
But I still have my analog requirements.
For that I want to use the EDS 4-chan 0-10V boards for my sensors and the EDS temperature, humidity, and pressure sensors for the environment.
As I stated above, my needs may not be as broad as some of your other users.
I just try to choose the best tools for the job; and OW seems most suited for (relatively) slow analog, not fast changing digital.
Thanks for the comments.
One of the things we're dealing with here is that the interaction between the EDS server and the plugin is one by parsing XML obtained through an http PUT command. For monitoring, we need to get the result and parse it to device states. Fairly straightforward, but there are some built in delays to allow the process to catch up with itself. For example, each refresh cycle starts out with a 5 second delay to ensure that the Indigo server is ready. Probably overkill, but I do that based on past advice from Matt and Jay (there's a chance that advice was situational, but I've taken to applying it to all of my plugins.) If I run the plugin in development without this delay, the process is pretty quick--I have a lot of development devices and the entire cycle completes in a half second. I'll consider adding the delay time as a plugin setting--and perhaps ship with no delay and instructions to increase the delay if there are problems. I agree that fast response times are very desirable.
For control, it's even more:
- query the status (as an EDS device state could have changed external to the plugin -- i.e., an alarm has been triggered),
- determine if the request is necessary (i.e., no need to send a relay closed command if it's already closed),
- send the command if necessary,
- heartbeat,
- query the status again to ensure the command was executed properly,
- resend the command if necessary,
- repeat until successful (or fail on a number of tries),
- report the result back to the plugin device.
When sending these commands, I've still found the EDS to respond nearly instantly.
I haven't worked out some potential use cases yet--for example, a magnetic switch. It would be great to be able to have an event reported in Indigo in real time. But it gets complex pretty quickly as we might want that information in a second or less, but we wouldn't necessarily need temperature updates that quickly. Having the plugin make queries every second is asking a lot. It would be great if we could interact with the EDS via telnet (or similar) and keep a channel open for real time reporting; I'll do some more research, but I don't know that it's currently possible. I suppose another possibility is to use multiple threads with different refresh rates, but I haven't tried that approach.
Regardless, the existing plugin as it stands right now would continue to work as it has, so no worries there.
Again, thanks very much for the comments. Cheers!
Dave