Revise QX vendor:voltronic:* buzzword setting; also these modes are not alarm material#3024
Merged
jimklimov merged 4 commits intonetworkupstools:masterfrom Jul 29, 2025
Merged
Conversation
… buzzword setting; these modes are not alarm material [networkupstools#2494] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ng [networkupstools#2494] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…s to be complete sentences [networkupstools#2494] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
jimklimov
added
need testing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes: #2494
Also fixes what I now think was a wrong solution made in #2850 (shipped in NUT v2.8.3 release), with
buzzmode_set()used in method that reports device capabilities - not its current status.@spacelama: One point I am not sure about is that the mapping to call
voltronic_mode()seems to fire for both"ups.alarm"and"ups.status"setting (so probably handling same device response to(QMODquery twice in a row), and the method seems toswitch (item->value[0])so if I read that correctly - it would be reacting to only one of the possible states in that string, whichever state's character comes first? Maybe it should loop over all chars?.. I've added some debug logging (to be seen at verbosity 4 or above) to help check what string it receives. Hopefully the buffer is NUL-terminated - but the logging should truncate it then; let me know if there are problems with it (if truncation is reported, or if any segfault etc. happens due to logging).Related to that point, again if my reading is correct, any UPS handled by this protocol code would only show some one token in
ups.statusand/or some oneups.alarmat any given time? e.g. it would never show something like "OL CAL" even if it is both calibrating and fed by wall power in fact (andQMODresponse might even report both of that)?Finally, IF the
QMODresponse only somehow reports a change since last query (not likely, but...) or if we do only see some (semi)random one of the device states, the reports about being in ECO/Converter modes may be very much fleeting - blink and they are gone. How did it behave with the originally reported alarm in #2494 - did it persist, or did it pop up once when the UPS switched to ECO mode?Also currently there is no handling (was no alarm) for Advanced ECO mode. I do not know if it is reported via some special character in QMOD or elsewhere, or is same as ECO as far as reporting goes (per man page, in practice they are quite different - with PFC/inverter kept running or off, while the load is fed via bypass).
Generally, if possible, can you please double-check these suspicions in practice, so I know if they are founded or if I misread the code? :)