starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

BTU field and calculation per rack #3888

New Issue
Closed
opened 2025-12-29 18:31:47 +01:00 by adam · 9 comments
adam commented 2025-12-29 18:31:47 +01:00
Owner
Copy Link

Originally created by @TheFrenchCanadianEh on GitHub (Jul 23, 2020).

Environment

  • Python version:
  • NetBox version:

Proposed Functionality

A new field for every device requesting BTU (heat generation) providing a calculation per rack. This will help in determining heat creation per rack, and make for easy calculations for branch hub room cooling requirements.
A means of calculating BTU based on wattage would also be beneficial

Use Case

A new branch office is being built, and cooling requirements are needed by the contractor.
If all devices in the rack were assigned a BTU rating, or a means of calculating it based on wattage, a quick per rack calculation would be feasible.

Database Changes

A new field per device would be required

External Dependencies

unknown

Originally created by @TheFrenchCanadianEh on GitHub (Jul 23, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: <!-- Example: 3.6.9 --> * NetBox version: <!-- Example: 2.7.3 --> <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality A new field for every device requesting BTU (heat generation) providing a calculation per rack. This will help in determining heat creation per rack, and make for easy calculations for branch hub room cooling requirements. A means of calculating BTU based on wattage would also be beneficial <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case A new branch office is being built, and cooling requirements are needed by the contractor. If all devices in the rack were assigned a BTU rating, or a means of calculating it based on wattage, a quick per rack calculation would be feasible. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes A new field per device would be required <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies unknown
adam added the type: featurepending closure labels 2025-12-29 18:31:47 +01:00
adam closed this issue 2025-12-29 18:31:47 +01:00
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 24, 2020):

Can you elaborate on the proposed new field please? For example, what would the range of valid values be? Under what circumstances would it be required? How would it be conveyed to the user?

@jeremystretch commented on GitHub (Jul 24, 2020): Can you elaborate on the proposed new field please? For example, what would the range of valid values be? Under what circumstances would it be required? How would it be conveyed to the user?
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@lps-rocks commented on GitHub (Jul 24, 2020):

To add to the discussion, I believe this should be tracked more similarly to power, have an average value and a maximum value. Since we all know servers can have some pretty outrageous BTU / Wattage ratings based on power supplies and not based on actual thermal output and power consumption.

Intel has a specification here: https://www.intel.com/content/www/us/en/support/articles/000006784/server-products.html - for generating BTUs based on consumed wattage. It boils down to watts * 3.41214 = BTU - This may just need to be a displayed value?

@lps-rocks commented on GitHub (Jul 24, 2020): To add to the discussion, I believe this should be tracked more similarly to power, have an average value and a maximum value. Since we all know servers can have some pretty outrageous BTU / Wattage ratings based on power supplies and not based on *actual* thermal output and power consumption. Intel has a specification here: https://www.intel.com/content/www/us/en/support/articles/000006784/server-products.html - for generating BTUs based on consumed wattage. It boils down to watts * 3.41214 = BTU - This may just need to be a displayed value?
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@TheFrenchCanadianEh commented on GitHub (Jul 24, 2020):

Hello Jeremy,

It would be a decimal based field (although you could force an integer)
that would show up when defining every device.
The range of values per device would be from 0 to likely no more than 15000
BTU/hr for a larger chassis switch with multiple blades and power supplies.
It would be required when building a hub room, and calculating the cooling
required for the space. This could feasibly be used to calculate your hot
isle in a DC too.
I would like it to be conveyed as that same BTU field entry for each
device, and a rack summary of all entered BTU's. You could in theory keep
expanding this calculation out for the row if multiple racks are present.
Anything larger than a row, Data Center engineers would be involved and
would be spec'ing cooling for total floor space growth.

Use case: When I spec'd a new hub room for a branch office, the general
contractor always wants a BTU calculation to decide on cooling for the
space.

If you were to look up a current switch, say a Cisco 9300
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/hardware/install/b_c9300_hig/b_c9300_hig_appendix_0110.html
tech
sheet and search for BTU, each power supply size has a different output.

The formula for calculating BTU/hr is: Heat Dissipation (Watts) x
3.4192 = BTU/Hr. So if a server has a heat dissipation (output) of 500
Watts the thermal or heat energy generated is 1709.6 BTU/hr.

Please let me know if you have further questions or need detail. I
appreciate the quick response to this feature request. It should be quite
easy to implement as an optional field.
If you do create a rack summary, maybe add a warning that "Device X in U32
does not have a BTU value assigned, using 0 for this calculation"

Regards,
David Corriveau
m. 226.988.4019

On Fri, 24 Jul 2020 at 12:27, Jeremy Stretch notifications@github.com
wrote:

Can you elaborate on the proposed new field please? For example, what
would the range of valid values be? Under what circumstances would it be
required? How would it be conveyed to the user?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/4889#issuecomment-663621556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQMEIY73VFZOT7D6IKONYPDR5GYZDANCNFSM4PFZMOLA
.

@TheFrenchCanadianEh commented on GitHub (Jul 24, 2020): Hello Jeremy, It would be a decimal based field (although you could force an integer) that would show up when defining every device. The range of values per device would be from 0 to likely no more than 15000 BTU/hr for a larger chassis switch with multiple blades and power supplies. It would be required when building a hub room, and calculating the cooling required for the space. This could feasibly be used to calculate your hot isle in a DC too. I would like it to be conveyed as that same BTU field entry for each device, and a rack summary of all entered BTU's. You could in theory keep expanding this calculation out for the row if multiple racks are present. Anything larger than a row, Data Center engineers would be involved and would be spec'ing cooling for total floor space growth. Use case: When I spec'd a new hub room for a branch office, the general contractor always wants a BTU calculation to decide on cooling for the space. If you were to look up a current switch, say a Cisco 9300 <https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/hardware/install/b_c9300_hig/b_c9300_hig_appendix_0110.html> tech sheet and search for BTU, each power supply size has a different output. The formula for *calculating BTU*/hr is: *Heat Dissipation* (Watts) x 3.4192 = *BTU*/Hr. So if a server has a *heat dissipation* (output) of 500 Watts the thermal or *heat* energy generated is 1709.6 *BTU*/hr. Please let me know if you have further questions or need detail. I appreciate the quick response to this feature request. It should be quite easy to implement as an optional field. If you do create a rack summary, maybe add a warning that "Device X in U32 does not have a BTU value assigned, using 0 for this calculation" Regards, David Corriveau m. 226.988.4019 On Fri, 24 Jul 2020 at 12:27, Jeremy Stretch <notifications@github.com> wrote: > Can you elaborate on the proposed new field please? For example, what > would the range of valid values be? Under what circumstances would it be > required? How would it be conveyed to the user? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/4889#issuecomment-663621556>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AQMEIY73VFZOT7D6IKONYPDR5GYZDANCNFSM4PFZMOLA> > . >
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Jul 24, 2020):

The BTU field should not be added to device templates. As it will already contain the average and max watts and the value should be derived from this.
These values (Equipement, rack, row, etc. BTUs) should be available to be queried/displayed via the API and UI even though it is a derived value.

@xkilian commented on GitHub (Jul 24, 2020): The BTU field should not be added to device templates. As it will already contain the average and max watts and the value should be derived from this. These values (Equipement, rack, row, etc. BTUs) should be available to be queried/displayed via the API and UI even though it is a derived value.
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Aug 6, 2020):

I like the idea of @xkilian but for this we should make the "Maximum draw" field to an required input if device-template created.
if we check the device-template repo we could see there are this values insert:

power-ports:
- name: PS1
  type: iec-60320-c16
  maximum_draw: 1100
- name: PS2
  type: iec-60320-c16
  maximum_draw: 1100

i personally thinking about the btu calculation could be some part of plugin maybe ?

@tb-killa commented on GitHub (Aug 6, 2020): I like the idea of @xkilian but for this we should make the "Maximum draw" field to an required input if device-template created. if we check the device-template repo we could see there are this values insert: ``` power-ports: - name: PS1 type: iec-60320-c16 maximum_draw: 1100 - name: PS2 type: iec-60320-c16 maximum_draw: 1100 ``` i personally thinking about the btu calculation could be some part of plugin maybe ?
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 27, 2020):

@TheFrenchCanadianEh can you please update your original post to specify the exact changes being proposed?

@jeremystretch commented on GitHub (Aug 27, 2020): @TheFrenchCanadianEh can you please update your original post to specify the exact changes being proposed?
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@TheFrenchCanadianEh commented on GitHub (Aug 27, 2020):

I think xkilian and Oliver identified the better way to proceed. This
should result in completion of the requested behaviour.

On Thu, Aug 27, 2020, 1:59 PM Jeremy Stretch notifications@github.com
wrote:

@TheFrenchCanadianEh https://github.com/TheFrenchCanadianEh can you
please update your original post to specify the exact changes being
proposed?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/4889#issuecomment-682102959,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQMEIY5J2SS7OTSRFQM6YKDSC2NHLANCNFSM4PFZMOLA
.

@TheFrenchCanadianEh commented on GitHub (Aug 27, 2020): I think xkilian and Oliver identified the better way to proceed. This should result in completion of the requested behaviour. On Thu, Aug 27, 2020, 1:59 PM Jeremy Stretch <notifications@github.com> wrote: > @TheFrenchCanadianEh <https://github.com/TheFrenchCanadianEh> can you > please update your original post to specify the exact changes being > proposed? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/4889#issuecomment-682102959>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AQMEIY5J2SS7OTSRFQM6YKDSC2NHLANCNFSM4PFZMOLA> > . >
adam commented 2025-12-29 18:31:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 1, 2020):

FYI this issue will soon be closed if the original post is not updated to detail the specific change(s) being proposed.

@jeremystretch commented on GitHub (Sep 1, 2020): FYI this issue will soon be closed if the original post is not updated to detail the specific change(s) being proposed.
adam commented 2025-12-29 18:31:49 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Sep 30, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Sep 30, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3888
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?