Page 1 of 3

Upcoming OWServer Plugin Update

PostPosted: Tue Sep 15, 2015 12:59 pm
by DaveL17
It's almost time to make available the next version of the OWServer plugin which looks to include the following enhancements:

1. Adds support for EDS0081 (Octal Current Input) - still ironing this one out, as I don't have a good XML base to work from. If any users of the plugin have this sensor type on their network, please forward the appropriate snippet of the details.xml file. Also looking for good XML for the following sensor types:
    EDS0064 - Temperature Sensor with Relay
    EDS0065 - Temperature and Humidity Sensor with Relay
    EDS0066 - Temperature and Barometric Sensor with Relay
    EDS0070 - Vibration Sensor with Relay
    EDS0071 - RTD Reader, 4 Wire with Relay
    EDS0080 - Octal 4-20 milliamp input with Relay
    EDS0083 - Quad 4-20 milliamp input with Relay
    EDS0085 - Quad 0-10 volt input with Relay
    EDS0090 - Octal discrete input/output with Relay
If you have any of these sensor types on your network, please contact me via PM.

2. Adds support to automatically detect all OW-SERVER-ENET servers on the local network. This bit of kit will automatically detect all servers running on the local network and pre-populate the plugin with the relevant IP addresses of the servers themselves. If any users of the plugin that have more than one server on their network are willing to be alpha testers, please contact me via PM.

3. Adds initial support to write select data back to the 1-Wire network. This is a work in progress, but with the ultimate goal of being able to directly control select 1-Wire devices and write data back to sensors where that would be useful (i.e., Low and High Alarm States, Conditional Search States, Relay states and so on.) I am also looking for a few alpha testers for this functionality as well. If you would be willing, please contact me via PM.

For the second and third requests, the amount of work involved would be very minimal. I would send you small segments of code to run against your 1-Wire network, and request a short summary in return. You would not be required to install preproduction versions of the plugin. If you would be willing to help out, it would be most appreciated.

Dave

Re: Upcoming OWServer Plugin Update

PostPosted: Sun Oct 04, 2015 11:39 am
by DaveL17
So perhaps "almost time to make available" was a bit optimistic. :D This has proved to be much more of a black hole than I anticipated (and in a very good way.) I still have a ways to go before I'm ready to release this into the wild, but I thought an update might be nice. Here's some shots from my development environment.

Device types with dynamic statuses and type-appropriate icons:
Screen Shot 2015-10-04 at 11.57.24 AM.png
Screen Shot 2015-10-04 at 11.57.24 AM.png (50.22 KiB) Viewed 7620 times


Supported device types. These are all coded for sensor types and custom device states and optional relays, etc.
Screen Shot 2015-10-04 at 11.58.39 AM.png
Screen Shot 2015-10-04 at 11.58.39 AM.png (121.73 KiB) Viewed 7620 times


Work continues on custom device configuration settings. I think at initial release, these will probably be read-only. Ultimately, however, data entered here will affect the subject device as a setting.
Screen Shot 2015-10-04 at 11.59.39 AM.png
Screen Shot 2015-10-04 at 11.59.39 AM.png (101.45 KiB) Viewed 7620 times


Until such time as device settings dialogs are implemented, we have the ability to write to any writable data element on an ad-hoc basis:
Screen Shot 2015-10-04 at 12.08.14 PM.png
Screen Shot 2015-10-04 at 12.08.14 PM.png (59.25 KiB) Viewed 7620 times


One big thing that I need to iron out is how best to deploy multisensors. Right now, I'm leaning towards device groups -- just to whet your appetite. :D
Dave

Re: Upcoming OWServer Plugin Update

PostPosted: Sun Oct 04, 2015 12:50 pm
by jens
Nice work Dave,

Cant wait to test... :)


//Jens

Re: Upcoming OWServer Plugin Update

PostPosted: Sun Oct 04, 2015 12:58 pm
by DaveL17
jens wrote:
Nice work Dave,

Cant wait to test... :)


//Jens

Thanks Jens.

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 10:05 am
by 4billl
I notice your plugin now supports the EDS0085 quad voltage input. But I cannot find such a device on the EDS website.
The closest device I can find in the OW-IO-AI8 - Octal Analog Input or the OW-IO-AI4 - Quad Analog Input.
Will the OW-IO-A14 work with your plugin or can you tell me where I can find an EDS0085 device?

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 10:14 am
by jens
Any new beta coming soon to my 8 Chanel switch??

//Jens


Sent from my iPhone 6 using Tapatalk

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 12:19 pm
by DaveL17
4billl wrote:
I notice your plugin now supports the EDS0085 quad voltage input. But I cannot find such a device on the EDS website.
The closest device I can find in the OW-IO-AI8 - Octal Analog Input or the OW-IO-AI4 - Quad Analog Input.
Will the OW-IO-A14 work with your plugin or can you tell me where I can find an EDS0085 device?

The data I used to support the EDS0085 came directly from example output from a server with that sensor installed. The documentation lists the OW-IO-AIX-10V as EDS0082 (Octal) and EDS0085 (Quad). It shows the OW-IO-AI8-10V as the one available in an EDS enclosure and OW-IO-AI4-10V as a bare bones board--but all combinations may be available. This document should help you find what you're looking for. As to your other question--whether it will work with the plugin--is dependent on how the board reports. I have support for EDS0082 and EDS0085 built in, so it *should* work out of the box.

All that said, there is still work that needs to be done to build native support of I/O devices. What I mean by that is that it should be possible now to be able to address the channels through direct commands using Python (with the plugin acting as an intermediary), but I hope to make it much more straightforward in the future.

Cheers,
Dave

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 12:39 pm
by DaveL17
jens wrote:
Any new beta coming soon to my 8 Chanel switch??

//Jens

Hi Jens - Fine grained control of the 8 Channel switch--as well as the quad--is still in the works (see also my post above.)

As I started to look into it, this became much more complicated than at it might seem at first blush, and I've been thinking about the best way to implement it. One way would be to change the device definition to be a combination device that would present in Indigo in much the same way that a multi sensor does. That is, one parent device with sub-devices. On the face, this all seems simple, but it gets much more complex due to the nature of the way that the server communicates with the device.

Anyway, I haven't heard much in the way of reports of undocumented features from my last big update (also known as bugs), and now that the holiday crush is over, I will make a resolution to look into this with gusto. The results of this effort will have broad reaching implications for most OWServer devices.

Cheers,
Dave

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 3:12 pm
by jens
It is nice to hear that you work going forward Dave, :) as soon as you have some beta version I like to test it :)

//jens


Sent from my iPhone 6 using Tapatalk

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 4:52 pm
by DaveL17
I have big plans! Unfortunately, I also have small spare time.


Sent from my iPhone using Tapatalk

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 06, 2016 11:22 pm
by jens
Same problem for me Dave


Sent from my iPhone 6 using Tapatalk

Re: Upcoming OWServer Plugin Update

PostPosted: Tue Jan 19, 2016 9:11 pm
by DaveL17
The more I've dug into this, the more worms I found in the can. :D

Approach 1: Using the Indigo Device Factory, I can create combined devices like so:
Screen Shot 2016-01-19 at 7.17.32 PM.png
Screen Shot 2016-01-19 at 7.17.32 PM.png (65.62 KiB) Viewed 7200 times

But the device interface starts to be cluttered with buttons pretty quickly. This technique generates individual devices for each function--like a multi-sensor--and the example above results in seven separate devices. An 8-Channel switch with relay would be at least 10 devices. Further still, if I use the Device Factory, all future devices must be constructed in this fashion.

To create a new device in the Device Factory, the device creation dialog looks like this (bear in mind this is in development):
Screen Shot 2016-01-19 at 7.27.28 PM.png
Screen Shot 2016-01-19 at 7.27.28 PM.png (81.67 KiB) Viewed 7200 times

This dialog will become increasingly complex when accounting for all the possible features across all possible device types. For these reasons, I think the Device Factory might not be the best approach for the OWServer plugin. (That said, I think the Device Factory is incredibly powerful and it was a great learning experience for me.)

Approach 2: The second option that I've come up with (but not tried) is to have plugin device types linked to features rather than physical devices. For example, a temperature device type could be used for a DS18B20, DS18S20, EDS0068, etc. If the device has an optional relay, you would add a new relay device. If you don't care to use a feature, don't create the device. Have an 8-Channel switch but you're only using 4 of the channels? Only create four switch types. Link them to the appropriate EDS Server IP and ROM ID and you're in business. I think that this may be the most economical approach to take and I think it meshes more closely with native Indigo device implementations.

Regardless, either approach would be a fundamental ground-up rewrite of the plugin and I'll be abandoning all current device types in future versions of the plugin. Existing implementations would continue to work, but plugin updates would completely break them. In other words, users could continue with today's implementation indefinitely with no concern. It would be great be able to support all approaches in one plugin, but I don't think that's feasible. Believe it or not, the development version of the devices.xml file while incomplete is well over 10,000 lines!

So here's my plan. I plan to increment the current production version of the OWServer plugin to version 1.0.0 and halt all future development of it (but would still try to fix any bugs found in the future.) Then I will fork the plugin to become OWServer Next Gen (or something like that) and all future development would occur with that version. Users wanting to move to the next gen version would be required to rebuild their implementations. It's unfortunate that this kind of drastic change is necessary, but when I first developed the plugin, my vision was 100 percent monitoring. When I started to include control, it became clear that my initial vision wouldn't scale well.

Because this is such a significant change of course, I would very much appreciate hearing current users' opinions about this plan or ideas for an even better Approach 3. :D
Dave

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 20, 2016 9:02 am
by 4billl
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.

Re: Upcoming OWServer Plugin Update

PostPosted: Wed Jan 20, 2016 5:11 pm
by DaveL17
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

Re: Upcoming OWServer Plugin Update

PostPosted: Thu Jan 21, 2016 11:11 am
by 4billl
Dave -
In most cases, my analog inputs change very slowly - temperature, humidity, tank levels - so the delay to the response is OK.
But in a few cases, namely water pressures from pump actions, faster reporting would be desirable.
Bill