- Platform information:
- Java Runtime Environment: V21, according openHAB installation
- openHAB version: 5.0.1
- Code: rulesDSL
- Logo BA8
- openHAB gets operated in a docker container
- Issue of the topic: Analog values get stated as 0 irregular
Reading analog values from Logo BA8 devices does give me irregular and at different frequencies
the Value 0 even typically the Value shall be different from 0.
First I was under the impression that perhaps the analog input for logo BA8 may cause the issue, now I have the same issue with an simple circuit and an explanation by potential analog input issues of the Logo became a more and more weak argument. I programmed a Trap to the LOGO-program that shall count if a particular analog input has a 0-Value to get an idea it´s related to Logo BA8 or related to the PLCLogo Bindung. Result does tell a clear message: There are no 0-Values at the analog input indicated by the trap but 0-Values are stated in openHAB.
In addition tracing analog items with the Logo-IDE does not show any 0-Value while trials.
The 0-Values are just exceptional in a one time poll interval.
The use of a filter that collect 256 cycles a Value and gives back the mean does also get shown as a 0-Value sometimes. Next indicator that there´s something on the software, not the hardware side.
Example configuration in openHAB:
Thing:
Bridge plclogo:device:Logo2 [ address="192.168.xxx.yyy", family="0BA8", localTSAP="0x3000", remoteTSAP="0x2700", refresh=200 ]
{
Thing analog AI_L2 [ kind="AI"]
Thing analog AQ_L2 [ kind="AQ"]
Thing analog AM_L2 [ kind="AM"]
Thing analog NAI_L2 [ kind="NAI"]
}
Item:
Number NUM_AI_L3_AI2 "L3 AI2 [%.0f cV]" { channel="plclogo:analog:Logo3_lf:AI_L3:AI2" }
As in general analog values get stated correct I assume the setup of the binding is correct.
What may be a root cause that analog values get stated as 0 even in the LOGO BA8 a significant different value is shown ? How does Moka7 library act here ?
The mentioned issue does happen for all analog items: AI input, AM analog Marker, NAI network input.
Being a bit helpless at present bit this occasionally issue.
As this values get persisted in influxDB2 a code solution in rulesDSL simply to block any 0-value code is not an option here.
Any comments or a need of further information pls. let me know.
Frank