https://www.umh.app logo
Join Discord
Powered by
Issue: Sensorconnect after some time
# umh-support
t
Issue: Sensorconnect after some time stops on error.
When I first created this, it worked fine for some time...then I come back to it....and it has these errors.
data-flow-component-logs-183d42a1-b01c-4e1a-b07b-baaf74334de
This is running in UMH-Lite docker, on raspberry pi....but I orginally had it running on a VM with rocky linux and expreienced the same.
j
this could be the firmware issue we were talking about :/ we thought requesting data once every 1 secodn is enugb ffer, but it is apparently not
let us check
as far as I remember cycling the ifm device fixes it, but let me check that
t
Firmware of the ifm master?
I missed that conversation
j
yes, but let me confirm this
t
i'm looking to see what my version is now
j
when strting up, it will show you an info message
so benthos-umh
t
j
so we have it running for a couple of days now on this firmware version: AL1x4x_fw_mo_f7_v3.1.70 this is still not the experimental firmware we got, but is more recent. the most recent one is 3.1.97
how many io devices did you connceted?
t
Current version on the website is 3.1.97
I have 2 sensors
j
I remember this error happened in these cases: 1. asking multipel times per second on a non-experimental firmware resulted in the devices crashing and requiring a power cycle. we asked ifm and got an experimental firmware 2. maybe some elements of it were already solved in the recent firmware updates, but we know that requesting the data multiple times per second still fails here (when not using the experimental firmware) 3. it was also influenced by the number of connected devices. we have currenty 3 connected to an AL1342, so it should work wirth 2 devices but once every second should be enough buffer. sorry for the chaos there, but I wish ifm would have jsut fixed this issue
uif you power cycle the master, it should work again
t
I'll upgrade fw
and see how things go
j
keep me up to date on this, maybe we need to add an additional firmware check on this
how did it go?
did the firmware upgrade fix it?
t
j
this is really weird, I have the exact same model here with even more sensors.
t
do you have that "experimental" fw?
Here's my fw now...
j
i will check that, not that I have that one. let me update it to the one that you have
upgrading now
AL1x4x_fw_mo_f7_v3.1.97 now I have this firmware. let me check if this happens now for me as well
t
I don't know how long it takes....I just let it run over night...and checked it when you asked
j
started the test now with the new firmware, let's see if I can reproduce
t
I came back this morning with it disconnectd again
it doesn't self recover, I have to save&deploy
j
oh, so it is not the firmware if you can "reset" it by re-deploying benthos. let me then take a closer look, this already helped a lot
I can confirm btw that data is not landing up in the historian
I can reproduce, it seems to be a bug in sensorconnect and not in the firmware. the firmware one we seemed to circumvent by only requesting the data once per second
found the issue! it should have happened every 9.1hours. ifm does not allow the "cid" parameter, which is increased after every message, to go outside of -2 to 32764, which does not make sense at all (the max range of an int16 is 32767, so I assume they are actually using an int15 or something.....) fix should go out in the next mgmtcompanion version
PreviousNext
Powered by