Sensor losing connection

We use Cat6e 14ft. 568A STP

thank you for the input. This excludes cable length from the equation as they are within range. I assume that they are non-shielded.



jhg03a, can you confirm that:

- works fine with firmware 3.3

- with firmware 4 connection is lost

I've taken our new Pending unit and downgraded it from stock v4 to v3.30. I can't provide any specific action that causes it to stop working, but I will try to keep an eye on it.

jhg03a,



We have tried the same approach, downgrading to various older firmware versions but the problem still seems to be present no matter what we try. Hopefully you have better luck.

We'll see. I put a temperature/humidity probe and WetDry contact probe on it while it sits on a spare desk in my office.

Dan,



you mention losing connection of the probe. What do you mean? Not getting a value via SNMP for the probe?

jhg03a,



When you were experiencing the issue on the web server, how long does it take for it to occur again once you do a cold reboot of the unit?

I don't have a specific reproduce case, but my observations have been that it takes between 2 days and 2 weeks.

I've got my primary unit web interface dead again. It seem to happen more frequently the more probes are connected.

OK. We have compiled the info and passed it on to our dev team to further investigate.

In my case, we lose connection with the probe for 10 - 30 seconds every minute to every 3 minutes. The result is Red ? marks for the temperature and humidity readings in the web interface or only the temperature reading from the gateway being displayed and nothing else until refreshing the page several times and hoping for a connection to the probe.

Do you have other sensor probes that you can connect to your SensorGateway for testing? If yes, kindly do so.

Hi there

we have noticed that on v4 and v4.1 the sensor seems to loose connectivity to the main unit. This can be seen when you refresh the sensor status page for the device,. some times not all the probes data is returned and they do not always appear in the same order.

also if you look at the lcd display on the sensor with v4 and 4.1 you see the probes data disappear and come back (this does not happen on 3.06)

This issue also seems to interfere with Nagios reporting on the external sensor as it fluctuates from 0 degrees on minute to the correct temperature the next minute.

When the device is returned to 3.06 all works and the status page returns the correct info every time and Nagios is happy again. can you look at this as the cloud monitoring element of v4 is great but we can not migrate our 40 devices unless we can rely on it.

the issue with v4 and 4.1 and the probes has been seen on every device we have tried it on, which numbers about 10 so far.

We unfortunately do not have another probe to test with, we are a small company and only had the budget for the gateway and the one probe.



Bern just explained our exact issue to the T, in our case Icinga gets quite unhappy at times with it. His is unfortunately on a much larger scale than ours.

I've already committed our primary sensor gateway and it's associated sensor hub into production. Do the developers not have access to a set of test hardware? This seems reasonably reproducible to me when using a large number of sensors if you're patient.



It may not matter, but I did discover one configuration mistake in our environment that I corrected yesterday. The person who installed our sensor gateway and hub only connected the probe 1 cable between the two. This means the relay components were not showing up at all in the web configuration. This wasn't a big deal for us since we don't use the dry contact input/outputs.

As stated on May 18: We have compiled the info and passed it on to our dev team to further investigate.

I see that there is a new firmware version out now. Before I go and upgrade again, is this supposed to fix this specific issue or is this one still in the works?



Thanks.

My mistake, my colleague was mistaken and thought he saw a 4.3 release. Upon looking myself again I see that it is 4.1 and not 4.3

With v4.1 already released while this issue is being discussed, the next firmware upgrade will be the one that'll come with the fix.

Just installed 4 more sensors on v4. and 4.1

we have noticed that the sensor loss gets worse once the device is connected to the cloud options.

Hello,



Can you tell me what you mean by sensor loss?

If you watch the sensor LDC display and have 3 items on it say T1 T2 and Water for example on version 3.06 the displays never disappear the readings are constant and reporting in nagios never has issues..

On v4 and 4.1 on the LCD of the device one of the sensor readings disappears for a moment then returns

if you tie up a sensor to with myinfrastructure or your server room monitoring software or nagios to report on the devices you can see there are times when the sensor does not respond and the graphs respond with a 0 temperature.

the device itself does not report any issues as it seems to always know what the actual reading are.

if you email me your email address i will share the links to the devices so you can see the issues

Hello,



Please send it to our Lead Technician, [email protected].

For the sensor connection and OID issues,



A firmware update has just been released that fixes these issues:

serverscheck.com/sensors/firmware2.asp?v=5



For release notes, kindly check the following:

serverscheck.com/sensors/firmware_release.asp

After upgrading to v5 why does the screen display on the sensor still loose the external sensor or the water sensor readings for a few seconds?

Bern,



that is part of the design. the oled refresh is different and scrolls, compared to SNMP. You should monitor through SNMP.

The external sensors still disappear quite frequently on the web interface as well. Is that also part of the design?

yes due to the way javascript works on some configurations and the memory limitation of the device. Also you could try to increase the refresh rate of the web server or manually refresh the page.



Priority was on addressing SNMP & cloud in this firmware.

it should be OK in SNMP & cloud.