How is everyone modeling extended runtime batteries for UPS's ?

[stovakor]

So we have created UPS's in NetBox and we model those pretty easily with power outlets and power ports.
We're stuck on how to best model extended runtime batteries.

We use all APC equipment, and we're running into a few questions.

1. We can't seem to figure out the connector that the APC's are using for the extended runtime batteries to plug into the UPS's. It looks like its a variation of an Anderson SB50
   https://electronics.stackexchange.com/questions/308713/what-is-this-connector-on-my-ups-called
   https://objects.eanixter.com/PD321515.PDF

2. The extended runtime batteries have a hardwired power cord. How would we best model this power connection into NetBox? Does NetBox have the concept of an attached powercord? It's not a separate cable that connects the UPS to the runtime battery.

3. On the UPS, how would we model the extended runtime connector? Would it be a rear port? A power plug?

I'm curious what the rest of the community has figured out to model extended runtime batteries.

[jsenecal]

I think PowerPort/PowerOutlet combination should work fine. The types have some options or you could open a PR to add this Anderson type connector:
https://github.com/netbox-community/netbox/blob/develop/netbox/dcim/choices.py#L595-L607

I would go with "Other"

[mtinberg]

I am not sure that modeling the connection (port/cable/etc.) for the external battery pack matters, but knowing that an external battery pack is installed and what model of batteries are inside it are very important, both because the number/existence of an external battery pack needs to be configured in the APC config INI file, but also so that you can know how many of what kinds of batteries to order when they need to be refreshed. External packs should get Device Types / Device records and may be associated using Virtual Chassis (like a stack) or just share a name using a naming convention (ups-site-1, ups-site-1:battery1, etc. so /dcim/devices/?name__isw=ups-site-1 would find both) because they can be racked and take up their own physical space that can be tracked. You could create a report/script that sanity checks Netbox data if a particular UPS can connect to multiple external battery packs, to catch invalid configs before someone goes out to install it, maybe using a custom field or config context to store info about how many of what packs connect to which UPS. I think the Device Type records should get a custom field documenting which model of battery pack (eg. RBC11) and how many go into it, for both the main device and the external battery chassis, as well as a custom field on device for when a particular battery pack expires, so you can report on it including how many replacement batteries of what models are needed. The other thing to model is a Module Bay (newer Netbox) or parent/child Device Bay for the NMC slot and particular model of NMC card as the NMC is the actual Device you can access over a network, it's merely connected to and can monitor the batteries, the NMC firmware, config, serial numbers, etc. don't well represent the whole device. I haven't had time to do the research to figure out which RBC packs go to which Device Types, but that is definitely on my backlog somewhere 😉 — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: stovakor ***@***.***> Sent: Thursday, December 1, 2022 9:39 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] How is everyone modeling extended runtime batteries for UPS's ? (Discussion #11068) So we have created UPS's in NetBox and we model those pretty easily with power outlets and power ports. We're stuck on how to best model extended runtime batteries. We use all APC equipment, and we're running into a few questions. 1. We can't seem to figure out the connector that the APC's are using for the extended runtime batteries to plug into the UPS's. It looks like its a variation of an Anderson SB50 https://electronics.stackexchange.com/questions/308713/what-is-this-connector-on-my-ups-called https://objects.eanixter.com/PD321515.PDF 2. The extended runtime batteries have a hardwired power cord. How would we best model this power connection into NetBox? Does NetBox have the concept of an attached powercord? It's not a separate cable that connects the UPS to the runtime battery. 3. On the UPS, how would we model the extended runtime connector? Would it be a rear port? A power plug? I'm curious what the rest of the community has figured out to model extended runtime batteries. — Reply to this email directly, view it on GitHub<#11068>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMYI3QTIYQGFGJMFIM3WLDBDDANCNFSM6AAAAAASQ5SOBA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[stovakor]

I already create a module bay for the NMC on my UPS. I find it works great since I can add the ethernet interface as well as the I/O connections. I know which environmental probes are connected to which I/O port. works great.

I really like your idea about the battery packs being modules as well. That way we can see how many battery packs and what model each battery pack is.

[mtinberg]

Modules might work as well for RBC battery packs, but it's not like you can mix and match them, and they don't add ports to the Device so just having a custom field on the Device Type for the battery chassis with the type and another with the number should suffice, eg a SUA1500X413 takes 1x RBC7, so you really just need a Device Type for that model with custom_field ups_battery_type="RBC7" and ups_battery_number=1 as it'll be the same for all instances of the Device. When looking it up its only one more API call away from the Device record, eg you could get all the /dcim/device/?name__isw=ups-&status=active or ?manufacturer=apc&role=ups or whatever in one request and /dcim/device-types/?id=foo&id=bar&id=baz in another by extracting the unique list of device type IDs from the first response, then look at the two custom fields to match up the pack types/counts with your devices, with only two round trips to netbox and the DB. If you have to chase down a bunch of relationships individually from the main Device to the external pack Device to the Modules to figure out the RBC type and count that could increase the number of API calls by the number of Devices being looked up and turn into a whole bunch of round-trips of API calls to get the same data, or you end up needing to dump the whole data set into your script and do all the lookups in local variables. I'll get off on a tangent and take a look at this in the lab using Modules to see if that works better than custom fields (now that modules exist). https://www.apc.com/us/en/product/SUA1500X413/apc-smart-ups-1500-va-120v-usb-with-alarm-disabled/ — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: stovakor ***@***.***> Sent: Thursday, December 1, 2022 10:44 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] How is everyone modeling extended runtime batteries for UPS's ? (Discussion #11068) I already create a module bay for the NMC on my UPS. I find it works great since I can add the ethernet interface as well as the I/O connections. I know which environmental probes are connected to which I/O port. works great. I really like your idea about the battery packs being modules as well. That way we can see how many battery packs and what model each battery pack is. — Reply to this email directly, view it on GitHub<#11068 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5WRY6PYD3QY6Y73NLWLDIV5ANCNFSM6AAAAAASQ5SOBA>. You are receiving this because you commented.Message ID: ***@***.***>

[candlerb]

Apart from Modules, Netbox has an older and simpler feature called Inventory Items.

If just want to record that a particular UPS has a particular set of extended batteries installed, with the model and serial number of each battery, then maybe this is sufficient.

[mtinberg]

Yeah, they aren't really queryable remotely afaict, and don't have serial numbers that we are about, I can't tell over SNMP what the battery model is, but it's in the vendor data sheet for each device type and the same for all devices of that type, which is why adding fields to device type that are populated on APC SmartUPS makes sense to me. Actually I'm not sure I can query the model of extended battery pack from the NMC SNMP, that might be something I need to look up on the data sheet and store in the device type as well, so if an eternal battery is installed (which is configured/queryable) I know what model it must be, as long as SmartUPS only supports one external pack SKU type per model. I did mock up using module bays and modules in my lab but I think this just adds overhead and make querying more complex, you'd need to associate the correct battery module(s) for each instantiation of a Device, which is never variable and is just an extra step of administrivia, and you'd have to query /dcim/module-bays/ for all individual device IDs to get the modules, then filter that down to just batteries, or commit to a naming convention (eg "Battery#") to be able to match up the specific battery types with specific devices. At the end you want something like {"device_name": {"battery_model": count} } but using modules makes it harder to get there than just fetching the unique device types then just looking up a battery model and count from a custom field, looping over your devices just once (if you lookup each device type individually and cache the result) or twice. Sorry for the info-dump, I'm just thinking this through myself, out loud, because I need to write a tool to import data and decide on a schema for storing it for our field services team too. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Friday, December 2, 2022 2:53 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] How is everyone modeling extended runtime batteries for UPS's ? (Discussion #11068) Apart from Modules, Netbox has an older and simpler feature called Inventory Items. If just want to record that a particular UPS has a particular set of extended batteries installed, with the model and serial number of each battery, then maybe this is sufficient. — Reply to this email directly, view it on GitHub<#11068 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4YTIW6MGV3VS5MIXDWLG2HJANCNFSM6AAAAAASQ5SOBA>. You are receiving this because you commented.Message ID: ***@***.***>

[mtinberg]

I split the difference, creating an object custom field on device type pointing to module type so the different RBC models can be tracked in our inventory system (we use device-type/module-type custom fields to indicate inventory item ID and desired min/max levels), but the detail is still directly accessible, in fact I can get just the UPS units with battery FRU with one query. With a ups_battery_replacement_date field cached on Device (populated and audited against SNMP) I should be able to easily write a report that shows batteries in need of replacement in the next month, which devices and which battery modules, as soon as we input all the data. /dcim/device-types/?manufacturer=apc&cf_ups_battery_replacement_count__gt=0 { "id": 530, "url": "https://netbox/api/dcim/device-types/530/", "display": "SUA5000R5TXFMR", "manufacturer": { "id": 3, "url": "https://netbox/api/dcim/manufacturers/3/", "display": "APC", "name": "APC", "slug": "apc" }, "model": "SUA5000R5TXFMR", "slug": "sua5000r5txfmr", "part_number": "SUA5000R5TXFMR", "u_height": 7, "is_full_depth": true, "subdevice_role": null, "airflow": null, "front_image": null, "rear_image": null, "comments": "APC Smart-UPS 5000VA RM w/Transformer, 208V input and 120/208V Output", "tags": [], "custom_fields": { "item_number": 12345, "coldspares_needed": null, "hotspares_needed": null, "item_description": null, "ups_battery_replacement_count": 2, "ups_battery_replacement_type": { "id": 92, "url": "https://netbox/api/dcim/module-types/92/", "display": "RBC55", "manufacturer": { "id": 3, "url": "https://netbox/api/dcim/manufacturers/3/", "display": "APC", "name": "APC", "slug": "apc" }, "model": "RBC55" } }, "created": "2022-12-01T12:14:52.471542-06:00", "last_updated": "2022-12-02T10:45:18.661401-06:00", "device_count": 1 } — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Mark Tinberg ***@***.***> Sent: Friday, December 2, 2022 8:53 AM To: netbox-community/netbox ***@***.***>; netbox-community/netbox ***@***.***> Cc: Comment ***@***.***> Subject: Re: [netbox-community/netbox] How is everyone modeling extended runtime batteries for UPS's ? (Discussion #11068) Yeah, they aren't really queryable remotely afaict, and don't have serial numbers that we are about, I can't tell over SNMP what the battery model is, but it's in the vendor data sheet for each device type and the same for all devices of that type, which is why adding fields to device type that are populated on APC SmartUPS makes sense to me. Actually I'm not sure I can query the model of extended battery pack from the NMC SNMP, that might be something I need to look up on the data sheet and store in the device type as well, so if an eternal battery is installed (which is configured/queryable) I know what model it must be, as long as SmartUPS only supports one external pack SKU type per model. I did mock up using module bays and modules in my lab but I think this just adds overhead and make querying more complex, you'd need to associate the correct battery module(s) for each instantiation of a Device, which is never variable and is just an extra step of administrivia, and you'd have to query /dcim/module-bays/ for all individual device IDs to get the modules, then filter that down to just batteries, or commit to a naming convention (eg "Battery#") to be able to match up the specific battery types with specific devices. At the end you want something like {"device_name": {"battery_model": count} } but using modules makes it harder to get there than just fetching the unique device types then just looking up a battery model and count from a custom field, looping over your devices just once (if you lookup each device type individually and cache the result) or twice. Sorry for the info-dump, I'm just thinking this through myself, out loud, because I need to write a tool to import data and decide on a schema for storing it for our field services team too. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

________________________________ From: Brian Candler ***@***.***> Sent: Friday, December 2, 2022 2:53 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] How is everyone modeling extended runtime batteries for UPS's ? (Discussion #11068) Apart from Modules, Netbox has an older and simpler feature called Inventory Items. If just want to record that a particular UPS has a particular set of extended batteries installed, with the model and serial number of each battery, then maybe this is sufficient. — Reply to this email directly, view it on GitHub<#11068 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4YTIW6MGV3VS5MIXDWLG2HJANCNFSM6AAAAAASQ5SOBA>. You are receiving this because you commented.Message ID: ***@***.***>