This is posted on RIO, but may be the same on the EPIC as it’s a /manage API issue.
I am connecting an anemometer to the RIO powered channel 0 as a Switch Input / Powered Digital Input type.
When configuring the channel with a Frequency (Continuous) feature, that value is placed into the manage/api/v1/io/local/modules/0/analog/values response along with other analog channels in the RIO module.
2 issues:
When the wind stops and the on/off activity halts, the Frequency doesn’t go to zero. It stays at the last recorded frequency. The way I know there is no wind isn’t by using the input frequency, but by comparing it with the past 5 or so values, and if it hasn’t changed, I know the frequency is zero. I can assume the frequency is zero because wind isn’t very stable, but for more stable inputs this workaround won’t be adequate. Is this a bug, or is it the way it was intended to work?
So I thought I’d change the Feature to a Counter, and do some math to compute frequency based on the timestamp of my last reading, but the Counter value isn’t available on the manage/api/v1/io/local/modules/0/analog/values API call as is the Frequency value. For that, an independent API call to the channel is necessary. Is there a reason the Counter value isn’t a part of the /analog/values API response like the Frequency feature?
I have workarounds for both methods of reading the anemometer, so this isn’t blocking us. Just wanted to know if I’m missing something, or if this is an opportunity for improvement.
Thank you for building such a flexible I/O device. It’s one of a kind.
1: I can’t answer this very well regarding the I/O behavior, but it at least looks consistent with reading the channel itself.
2: All of our I/O endpoints in the groov Manage REST API are basically thin wrappers around the underlying OptoMMP memory map, so we’re always at the mercy of how it works. Some MMP addresses can be different data types, depending upon the context. The “/api/v1/io/{device}/modules/{moduleIndex}/analog/values” REST API endpoint is designed only for reporting analog channel values, but it uses an area of the memory map that happens to be “packed” with digital feature values for digital channels. So you’ve found a bit of undocumented behavior, at least from the perspective of the REST API.
Digital features can be either a floating-point or integer data type, depending upon the particular feature. Frequency values are floats, but counters are integers. Since this API endpoint is only designed for reading analog channel values, and not digital feature values, it only interprets the underlying memory as being floats. So it just happens to work for frequency.
Thank you for your response. It helps me understand the reasons for the inconsistencies. As @Beno mentioned below, it may be something that can be overcome, and considered a valuable addition for a future revision.
Either way, thank you for the clarification. We can get around the issues today, and it can only get better in the future. I love that about this platform!
