Search results

Ok cool. I have some "design-todo" on recognizing the different sensor types additionally - this is exactly the case about "Fan" types. The name based recognition is not enough in these cases, but I need to think about it properly - how best solve it.

I can check back bit later, when I can properly look them up, but quickly responding - they are not mandatory for basic usage. They are needed if you have a need to aggregate/filter data, in which case (when properly set), you can focus on certain entity or category. Of course if the regexp is...

HWiNFOProvider uses not-publishable parts/technology, but it's as lean as possible and brings the data transparently through. The include/import part of alike libraries is done (often, and in this case) through Nuget packaging, but the package is not included in the repository, so its not...

Oh thanks Martin! I'll wait and see if we need to do anything in the PromDapter layer after all :).

I didn't spot this properly at first. I'll add a separate layer outside the regexps where you separately can dictate the units per identified sensors. Might be regexp based itself. I also think we can (ab)use the existing working system as a base. So that you could "export" the unit data from...

Current version takes the unit from the sensor data as-is, without any adding or filtering. So I believe the difference comes from the sensor/driver or how HWiNFO represents it. I think I understand the problem here; I propose we add a layer of customization in Regex definition (or right...

Cool cool! I'm happy we got it sorted out quickly enough :-) As I said, its not clear... I should rename the "reference" properly so that it's not easy to be mistaken like that in the future. I have few ideas of listing the "unmatched/missing" metrics as well properly to be identified...

I believe its my fault - for not being clear about which config file to modify. There are two configs. One for "reference" and one that's actually used. The actually used config is located in common application data location, that is usually around C:\ProgramData\PromDapter I hope this was...

... also, quick and dirty fix for uniforming the sensor names is to rename them in HWiNFO. While this is far from perfect (the renaming is user-specific), its quick to do and test out... and its in fact the way I aligned Ryzen 2700X with its temporary sensor difference to my Ryzen 1xxx and Ryzen...

EDIT: If you have no previous experience of .yaml file editing, take a backup before editing. Yaml is sensitive to indenting of the file, so amount of spaces in the file matter. I'm glad to hear that! The basic design principle was indeed, that modifying the .yaml file should be enough for...

I'm happy to hear that :). Please let me know if you miss something in that, so I know to prioritize the development accordingly. I'll add more generic configuration next as well as clean up some of the event logging (not a big deal, but it does repeat the error every time when polled, which...

Apparently I failed to rebuild the HWiNFO provider properly after purchasing the license to obfuscator, so the trial version caused the 0.9.14 to expire 8th of April (as of about an hour before this posting). So 0.9.15 beta isn't feature wise different, but it shouldn't expire *knocks on wood*...

Hi, I just published first version on PromDapter, that does the same kind of thing with Prometheus + Grafana. Now I can't make any promises for any other TimeDB support, but I consider adding them, if they're straightforward from existing Prometheus requirements. You might want to check it out...

I'm happy to announce first public beta release of PromDapter - customizable Prometheus Adapter for HWiNFO. My personal motivation was to get centralized dashboard of small cluster of computers (3-5 in my case) to be part of home automation. When joining the Folding@Home and Rosetta@Home (and...