<div dir="ltr"><div>Hello,</div><div><br></div>I'm still alive :-) I use my nut-agent daily. Alf, I also use OpenNMS. That's the reason I wrote the snmp agent.<div><br></div><div>I would not start with a MIB from a specific vendor as NUT might already have to deal with more complex equipment. Check <a href="http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html">http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html</a> to compare them. However, I would also check some vendors MIB for inspiration.</div>
<div><br></div><div>The first job for a snmp-agent is to finish the MIB file. In my agent, I mapped upsc structure the best I could trying to keep the current structure and avoiding to rethink it. There is some difference between how information is represented in SNMP and the upsc output. SNMP uses tables and subtables while upsc uses free structs. Do not expect to keep the "input.transfer.reason" structure in SNMP or you'll get disappointed as it get worse for things like input.bypass.L1-L2.voltage. </div>
<div><br></div><div>The MIB I wrote is not ready but it is a nice start. I still uses the enterprise number from my current company. NUT should have its own (it's free <a href="http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers</a>). I guess anyone with a @<a href="http://networkupstools.org">networkupstools.org</a> email could request it. I also did not synchronized with the current MIB fields. There might be new ones that I did not considered. My MIB does not have write fields (for set and command) or traps. These would be also very interesting and required if you target for a completely upsc replacement.</div>
<div><br></div><div>There is some tools that help to generate C code from the MIB file (smidump?). I guess with a good MIB, the C part would be fast. I would just need to hook the snmp calls to internal NUT functions. It could attach to the machine snmp (as a AgentX), run a dedicated snmp server or both options.</div>
<div><br></div><div>An MIB is like an API and it should not break with new revisions. New versions generally only add new stuff. I think this is the critical part. As I said, I kept the MIB fields as close as I could to upsc in order to help NUT dev/users recognize the snmp fields from what they see in upsc. However, this might not generate an optimal MIB. Some tables could be split into subtables or even refactored completely. For example, ambientTable could not use fixed fields for temperature and humidity. It could use a sensor table (indexed by UPS index and sensor index) that have a name field for "temperature" and "humidity". As you already worked with opennms, you already know that with greater flexibility in a snmp table will result in a more complex setup for NMS tools. Sometimes, it is better to have fixed fields, with empty values, that you can directly refer to it than a field that depends on two values to identify what it is. Maybe the best solution would be to offer both.</div>
<div><br></div><div>I can help with this job, specially with the MIB part but I my dedication currently would be limited. </div><div>For a quick working solution, I suggest:</div><div><br></div><div>1) a NUT enterprise number and update my MIB to use it</div>
<div>2) check for new properties and update the MIB</div><div>3) generate C from the MIB</div><div>4) hook it to nut library</div><div><br></div><div>More flexible tables, traps, and write fields could be added futher.</div>
<div><br></div><div>Regards,</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div>---<br> Luiz Angelo Daros de Luca, Me.<br> <a href="mailto:luizluca@gmail.com">luizluca@gmail.com</a></div>
<br><br><div class="gmail_quote">2014-02-18 19:02 GMT-03:00 Arnaud Quette <span dir="ltr"><<a href="mailto:aquette.dev@gmail.com" target="_blank">aquette.dev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">hem, in the hurry of sending, I've forgotten a link...<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-02-18 22:45 GMT+01:00 Arnaud Quette <span dir="ltr"><<a href="mailto:aquette.dev@gmail.com" target="_blank">aquette.dev@gmail.com</a>></span>:<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><br><div>2014-02-16 8:31 GMT+01:00 <span dir="ltr"><<a href="mailto:alf@i100.no" target="_blank">alf@i100.no</a>></span>: <br>
</div></div></div></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
(...)<div class=""><br>
<div>
<br></div><div>That made me realize that it's still not referenced on the NUT Related Projects page.<br></div><div>(yup Charles, yet another unshared thing...)<br></div><div>This last point is now fixed:<br></div></div>
</div>
</div></div></blockquote><div><br><a href="https://github.com/networkupstools/nut-website/commit/6d503c1c7e9f235263927ee2186ae336eb3178a3" target="_blank">https://github.com/networkupstools/nut-website/commit/6d503c1c7e9f235263927ee2186ae336eb3178a3</a><br>
<br></div><div>Arno<br></div></div></div></div>
</blockquote></div><br></div>