We are considering building some interface units to support remote node deployments at our sites. Some of the information that would be useful would be the operating voltage, overall health and temperature of the nodes themselves.
Is any of this information available somewhere within the operating environment of the hardware/firmware of the Ubiquiti equipment that can be extracted for monitoring purposes?
Is any of this information available somewhere within the operating environment of the hardware/firmware of the Ubiquiti equipment that can be extracted for monitoring purposes?
"Overall health" isn't exposed as any single value but may not be a bad idea to have added.
CPU tempature I would have to look into before being sure one way or other, SNMP might have it but then again we might not have some library installed to allow it to pull that sort of data so it's very possible that isn't available.
We're especially interested in operating unconnected to infrastructure (such as AC power). At one point, when I went to check a node I could no longer see via the mesh network (due to the battery charge being too low to operate the node), I saw the LEDs on the NanoStation M2 cycling from left to right in a continuous pattern that I thought must be indicating a low-battery-charge condition, so the device must have some method of noticing that. It sure would be convenient to notice something remotely, via the network displays, about battery level getting low prior to the device leaving the mesh network, to indicate that a service visit would be required soon. If there's not already available something of this sort, I wonder whether a mod introducing an A/D from the battery voltage to something the CPU could see might be in order. It surely would be of widespread generic value to anyone operating a mesh network with remote nodes on (solar and) batteries.
To my knowledge this is nowhere in our code, it may be a low level hardware function on the DC to DC converter or it might be a low level fucntion of the MCU or could just be a fault scenario while the chip is dying (unable to sustain life)
All our source code access info is available here: https://www.aredn.org/content/source-code-access. You are encouraged to look through it and expand upon the code or feature sets and submit the improvement to the team for inclusion in a future version. You will also need to be willing to open your device and track the hardware (no one to date has to my knowledge done a full pin by pin schematic breakdown of the devices) If you find it going to a pin on the MCU there may be room to work with it but I'm not aware of any such pin at this time.
Note: The AREDN team does not support devices which have been modified, so while you may find use in opening your device and attempting ot modify it the AREDN team will not guarantee the firmware support on devices which ahve been previously opened. The AREDN team aims to provide tools for reliable trusted networks which can not be guaranteed when weather seals and boards have been physically moidified.
You may want to look at the functions of your Charge Controller if you have a battery site. For example on solar sites the TS-MPPT60 has ability to serve a full blown website with statistical history and configuration ability of the controller. We have a repeater locally that serves our CERT team that is 100% solar that uses this controller and we are able to monitor it with the mesh (they had the controller before the mesh and were happy when they found out they could see the data without hiking up the hill)
The mesh could also be tied into any datalogger that outputs (you could use a Serial to Ethernet converter if the device only has a serial port) for reviewing the history.
Honestly there is so much more you can do with this off node the advantages of performing this on node seem limited to me.
http://www.ebay.com/itm/Raspberry-Pi-3-Pi-2-Sense-HAT-with-Orientation-P...
Or use one of these Wireless Smart Outlet with Metering
http://www.ebay.com/itm/Incipio-CommandKit-Wireless-Smart-Outlet-with-Me...
Hope that helps.
The MikroTik "PowerBox Pro" would seem to be a no-brainer for this. PoE in, four PoE out, full-flavored router with VLAN switching built-in. It's built into a weatherproof box, too.
Looks to me like a perfect solution for putting several nodes on the same tower/mast. I've been looking into this to replace a design for an installation with three nodes on solar power, using a Pi and multiple injectors...
https://mikrotik.com/product/RB960PGS-PB
-Jonathan
Most MikroTik devices run on 24V passive injection. So does this one. It'll handle up to 48V, and do 802.3af/at, but you don't *have* to do that.
See the second paragraph in their brochure on the product:
https://i.mt.lv/routerboard/files/PowerBox_Pro-170508144017.pdf
Devices such as the MikroTik create some great opportunities for power distribution and monitoring, mast mounting whole nodes and wiring simplification, but it does not answer the reliability issue with respect to power sourcing. Currently, we run passive PoE injectors, singles or quads fed by 12-15 volts, but that requires lots of in and out jumpers for the passive PoE, but it allows us to use convenient power from power supplies, batteries, solar panels and vehicles in a plug and play manner.
The generation of 24V or 48V power can easily be accomplished with a boost module that takes 12-15V to 24V or 48V. These devices can be put in a watertight box with enough air space to keep cool by the 12-15V source and all is good. You can find 250W to 600W models from Geree and others on Amazon. Definitely use on with a much higher rating than what you think you need so that it runs cool.
73,
Gordon, W2TTT
201.314.6964
w2ttt@att.net
What you *feed* that with, 24V-wise, isn't part of what I was talking about. You'd just be replacing power supplies for a switch and up to four nodes with a single injector that puts out clean 24V into the PowerBox Pro, and from there run outdoor-rated ethernet cable to the nodes.
73,
Gordon Beattie, W2TTT
201.314.6964
The MikroTik devices contain the hardware for system temperature and voltage as well as voltage and current to each PoE interface. It's probably available via SNMP and I've seen a script to send it via syslog as well. This is all using native RouterOS. Not sure what is visible via OpenWRT. This is from a hEX PoE which has the same guts as a PowerBox Pro via winbox:
All of the other MikroTik models I have used (and its most of them!) have this data available.
Ian
-Damon K9CQB
As suggested by Ian, above, this is a great use of SNMP. Someone should run an SNMP Walk on one of these to determine if they're reporting these values in the standard reporting taxonomy.
Andre, K6AH
mtxrHealthGroup OBJECT-GROUP OBJECTS {
mtxrHlCoreVoltage, mtxrHlThreeDotThreeVoltage, mtxrHlFiveVoltage,
mtxrHlTwelveVoltage, mtxrHlSensorTemperature, mtxrHlCpuTemperature,
mtxrHlBoardTemperature, mtxrHlVoltage, mtxrHlActiveFan,
mtxrHlTemperature, mtxrHlProcessorTemperature,
mtxrHlCurrent, mtxrHlPower,
mtxrHlProcessorFrequency,
mtxrHlPowerSupplyState, mtxrHlBackupPowerSupplyState,
mtxrHlFanSpeed1, mtxrHlFanSpeed2
}
mtxrPOEGroup OBJECT-GROUP OBJECTS {
mtxrPOEName,
mtxrPOEStatus,
mtxrPOEVoltage,
mtxrPOECurrent,
mtxrPOEPower
}
from the MIB, it's in there :)
https://downloads.openwrt.org/releases/18.06.2/packages/mips_24kc/packag...
https://downloads.openwrt.org/releases/18.06.2/packages/mips_24kc/packag...
No guarantee this will get what is desired, but sure looks promising. More specifics of the hardware on mikrotik devices is needed to know how RouterOS is obtaining the information. Also assumes RouterOS can obtain this information on the models we are concerned about--the hardware supports this ability.
Joe AE6XE
Joe AE6XE
Using Linux Mint 18.
sudo snmpwalk -v1 -c public -m "/usr/share/snmp/mibs/Mikrotik.mib" 10.31.223.33
Timeout: No Response from 10.31.223.33
sudo snmpwalk -v3 -m "/usr/share/snmp/mibs/Mikrotik.mib" 10.31.223.33
snmpwalk: Timeout
Does snmpwalk -v1 -c public <IPaddress> system return anything?
Orv W6BI
system: Unknown Object Identifier (Sub-id not found: (top) -> system)
I installed with : sudo apt-get install snmp
The following NEW packages will be installed:
snmp
0 upgraded, 1 newly installed, 0 to remove and 404 not upgraded.
Need to get 155 kB of archives.
After this operation, 553 kB of additional disk space will be used.
Get:1 http://mirror.cc.vt.edu/pub2/ubuntu xenial-updates/main amd64 snmp amd64 5.7.3+dfsg-1ubuntu4.2 [155 kB]
Fetched 155 kB in 0s (410 kB/s)
Selecting previously unselected package snmp.
(Reading database ... 387554 files and directories currently installed.)
Preparing to unpack .../snmp_5.7.3+dfsg-1ubuntu4.2_amd64.deb ...
Unpacking snmp (5.7.3+dfsg-1ubuntu4.2) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up snmp (5.7.3+dfsg-1ubuntu4.2) ...
The "Unknown Object Identifier" message means that you probably need to download the standard MIBs on the computer where you are running snmpwalk. You can get around this by running <code>snmpwalk -v1 -c public 10.31.223.33 1.3.6.1</code>
If you want to use object identifiers, you'll need to install the MIBs. On Linux there is a package called <code>snmp-mib-downloader</code> that handles this automatically for you. After installing all the MIBs, you need to edit your snmp.conf file and comment out the <code>mibs : </code> line by inserting a # character in the first position. Then you can successfully use the "system" object identifier.