Disabling the MiB should work, if it doesn't, that's a bug.
Disabling the module also disables the code which removes the sensors and status (yes, herpaderp we should fix that somehow).
Please re enable the modules, disable the mibs and run discovery for the sensors module on that host with debugging and send me the output.
Adam.
Sent from BlueMail
On 21 Oct 2016, 13:04, at 13:04, Robert Williams Robert@CustodianDC.com wrote:
Hi,
I finished up just disabling all these hosts on Observium for all alerting features, in order to hide the 62 alerts (and make the frontpage usable again).
If anyone has any further suggestions on re-identifying or otherwise stopping the detection of these rogue items, it would be much appreciated :)
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com From: observium [mailto:observium-bounces@observium.org] On Behalf Of Robert Williams Sent: 19 October 2016 09:57 To: Observium Network Observation System observium@observium.org Subject: Re: [Observium] Carel / pCo Discovery
Hi Tom,
Thanks for that, I tried disabling the UNCDZ-MIB (under Device->Properties->MIBs) but that didn’t seem to do anything even after a rediscovery.
So, I tried disabling the ‘Sensors’ and ‘Status’ Poller modules, as well as the ‘Sensors’ discovery module (no discovery module for Status?).
This did remove the graphs from the main page of the device, but all the sensors and readings are still there, as well as continuing to show up on the main page as both Status and Alert events…
[cid:image001.jpg@01D22B9B.955DE690]
All 46 status items and all 62 alerts are from these devices ☺
As an aside, the homepage now doesn’t scroll down the list of alerts (there are too many and it’s locked to the top of the page) - so we now can’t see any other ‘real’ alerts on the main page any more. I guess you are not supposed to have this many things broken at once ;)
Any other ideas for making it all go away?
Cheers!
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Tom Laermans Sent: 19 October 2016 08:35 To: Observium Network Observation System <observium@observium.orgmailto:observium@observium.org> Subject: Re: [Observium] Carel / pCo Discovery
Hi Robert,
The values currently being identified come from Carel MIBs and are correct for Uniflair devices. It's not really handy that they are just i/o contact controllers where anything can be connected to any pin which indeed makes anything possible.
Easiest for you is to disable the UNCDZ-MIB for the affected devices, and the sensors will go away after next discovery.
Tom
On 19/10/2016 09:29, Robert Williams wrote: Hi all,
I see that there has just been an update to the detection of the Carel pCo controllers, which has added a lot of new sensor definitions for many people I expect (a good thing would have been an awful lot of work for someone which is appreciated of course!).
Unfortunately, as the pCo is a programmable unit (and we are an OEM/unit programmer for Carel) we use the units for a large number of custom applications across a number of our facilities and customers. Previously we weren’t getting any sensor-specific information via Observium for these units (just network, CPU, ram etc.) which is OK as we use other BMS systems to get the environmental data.
Since the last update, we are getting a load of sensors but unfortunately (since our units are programmed by us) they are now showing alarms across most of the output, for example:
[cid:image002.jpg@01D22B9B.955DE690]
The values being polled are also non-sensical because whatever the OIDs which are being used are either not aligned to anything we use or just totally irrelevant values.
Humidity example below (obviously it’s not 3,4 and 16 %):
[cid:image003.jpg@01D22B9B.955DE690]
Interestingly, we do also have some ‘official’ Carel chiller controllers (running genuine Airedale control pCO units, not our own) – and these are also showing crazy values as chillers (no matter where you get them from) do not have ‘Delivery Air Temperature’ or ‘Humidification Proportional Bands’ as they don’t’ deal with air directly - for example:
[cid:image004.jpg@01D22B9B.955DE690]
So it appears the detection logic is not just limited to incorrectly identifying our own custom controllers but also those of other manufacturers like Airedale, who also use Carel OEM pCO hardware like us.
With all this in mind, can I ask what is the best way to prevent these devices from being detected as “ Carel pCOWeb (Chiller Unit) “. So that they go back to being simple pCOWeb units with basic stats like Ethernet and CPU?
Example device data is:
[cid:image005.jpg@01D22B9B.955DE690]
So like I said at the start, I fully appreciate there was a lot of effort by someone to get all these sensors setup and that’s great for people using the software they were configured to detect. I just need to ‘not’ detect our units as being the same really.
Input welcome :)
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.commailto:Robert@CustodianDC.com http://www.CustodianDC.com
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.commailto:Robert@CustodianDC.com http://www.CustodianDC.com
observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium