This question was originally posted on DCIM Support by Enric Climent on 2015-10-29
Often the vitual sensors last value is "unplugged" How can I solve this situation? I've alarms associated with these virtual sensors and I nee to read always the right value.
This answer was originally posted on DCIM Support by Steven Marchetti on 2015-10-29
I'm assuming you're seeing this in DCE and not DCO.
What are you using to create the virtual sensors? NetBotz sensors? APC device sensors? 3rd party device sensors?
Are the devices themselves going off-line?
Do the sensors used to create the virtual sensors go unplugged?
What version of DCE are you using?
Do they report unplugged for a brief period (a single polling cycle) or extended periods like an hour or more?
How many sensors are doing this?
Are they all created from the same device(s)?
This comment was originally posted on DCIM Support by Enric Climent on 2015-10-29
Yes, I talking about DCE.
I've created virtual sensors from Netbotz sensors and the phisical sensors doesn't go unplugged, just the virtuals.
DCE version is 7.2.6
The sensors are unplugged for long period of time. I have more than 30 virtual sensor and a half are unplugged. All of them are created from two devices, two Netbotz 570.
This comment was originally posted on DCIM Support by Steven Marchetti on 2015-10-29
Maybe there's more to this configuration. Can you please elaborate. When you say they report unplugged for a long period, is that an hour, a day? Maybe they went unplugged and never came back? Has anything on the NetBotz appliance changed? Have the sensors been renamed? Anything?
Is the NetBotz appliance configured / discovered normally or is it set up in post only mode? If many virtual sensors are doing this, it sounds like it's either not communicating every time it is expected or the sensors themselves are potentially not reporting values every time. If you look at the data in DCE (not virtual sensors) and compare the data in the NetBotz appliance itself, do the values seem to match up? Next, compare the DCE data to the virtual data, how do they line up?
This answer was originally posted on DCIM Support by Steven Marchetti on 2015-10-30
You should not rename the virtual sensors. There is a known issue (k-base FA164229) which, although it should not cause the issue you're seeing, will have issues in different views. I was more concerned with the renaming the sensors being used to create the virtual sensors.
Either way, if the appliance and the data on DCE properly update but the virtual sensor does not, there appears to be an issue with either the virtual sensor itself or it's connection to the NetBotz sensor(s). What I would suggest for a test is to create a new virtual sensor. If you have a sensor that is based on one or more NetBotz sensors, recreate it exactly. Do not change anything about the sensors used or the virtual sensor itself. Does this new virtual sensor have the same issue? If not, does it work OK for a period of time but eventually go into the same state? If it does eventually go into the same state, what, if anything, was done to the NetBotz, DCE, or the virtual sensor in any way?
If the device is communicating properly and the target sensors have correct values, I don't know of any way to make the virtual sensors start working again but if we can figure out why it happened in the first place, maybe we can stop it from happening again.
Something else I just thought of, can you try and edit the sensor (not name). Edit the sensor, remove sensor(s) when in the edit window. Next, click add sensors and re-add the same sensor(s).
This comment was originally posted on DCIM Support by Enric Climent on 2015-10-30
When I say for long time it means always, never change. Only when I rename them, then appears as plugged but after few minutes come back to unplugged state. On Netbotz appliance all seems right and the physical sensors shows values.
It`s very estrange so when I rename the virtual sensor gets value but when I rename back to the original name it come back to unplugged state.
This answer was originally posted on DCIM Support by Valentin Kozlov on 2015-10-30
You need to check time settings both for DCE and Netbotz appliances.
I have seen such issue about year ago and the reason was in different time on Netbotz and DCE. The issue was resolved, when I set up NTP syncronization for Netbotz from DCE server.
This comment was originally posted on DCIM Support by Steven Marchetti on 2015-10-30
Good call. I had asked about the data and Enric seemed to indicate that the bot and DCE were OK but not the v-sensor. Although not specifically answered, if there are historical values for the v-sensor, this is indeed the next thing to look at. If there is no historical data, maybe this should be done still but is likely not the issue.
This comment was originally posted on DCIM Support by Valentin Kozlov on 2015-10-30
Yes, I've read. I have similar behavior - v-sensor shows values after creation or changes for some (equal to polling interval) and goes to unplugged state after next polling. There were data from physical sensors and everything looks fine, but v-sensors from some Netbotz goes to offline and from some appliances works as expected. So I've investigate this deeper and find out that time on problem botz was different from server time. I assume that it relied to Netbotz's feature to send packet of data instead of momentary sensor values.
This answer was originally posted on DCIM Support by Enric Climent on 2015-11-02
Thanks for your comments. The problem was due the netbotz regional settings so was different time than the DCE server.
Now the v-sensors are right.
This answer was originally posted on DCIM Support by Tomas Vitha on 2016-08-17
I had the same problem a couple weeks ago and it was indeed caused by incorrect NTP server settings (thanks, Valentin!). Correcting the settings and rebooting all relevant NetBotz appliances fixed the problem.
Discuss challenges in energy and automation with 30,000+ experts and peers.
Find answers in 10,000+ support articles to help solve your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!