Quoted from "va3sd"

Please tell me how can I create ticket or ask developers look into issue with sensors New: aquasuite X

This is no aquasuite bug. Whenever you are using more than one software to monitoring your system you can have side effects with this 2 monitoring instances.

Quoted from "sebastian"

Quoted from "va3sd"

Please tell me how can I create ticket or ask developers look into issue with sensors New: aquasuite X

This is no aquasuite bug. Whenever you are using more than one software to monitoring your system you can have side effects with this 2 monitoring instances.

But I can not use only one monitoring: AquaSuite does not have many data which could be monitored by Hwinfo, if I turned off AquaSuite monitoring and something happened with hwinfo (removed, stopped, freezed etc.)- all values in Aquasuite will be = 100.

For me it is 100% bug. You do not leave any options to setup default values if there are no data from external monitoring tool, such as hwinfo.

Quoted from "va3sd"

For me it is 100% bug. You do not leave any options to setup default values if there are no data from external monitoring tool, such as hwinfo.

sebastian, Martin (HWiNFO Author) mentioned that Aquasuite developers can contact him if you are going to implement it.

https://www.hwinfo.com/forum/threads/wrong-min-and-max-values-on-msi-z490-tomahawk.7806/post-33702

What Martin (author if HWINFO) suspects is that Aquacomputer is not using a global named mutex when polling this particular sensor. Using the mutex ensures that there are no polling collisions when multiple programs are polling the same sensor. HWINFO, AIDA64 and SIV all use mutexes to poll system sensors which is why these programs can be run simultaneously. Corsair ICue is an example of a program that does not use global named mutexes which is why iCue cannot coexist with HWINFO, SIV, or AIDA64. I am not a programmer, just restating what Martin said he thought was causing the issue. It seems that AQS does use mutexes or some other polling interlock to avoid polling collisions for other sensors, but not this one, so OP is seeing polling collisions. In the HWINFO thread that you posted a link to Martin says, "I can't tell this exactly as I have no insight into their code. There are several places and different methods to be used for proper synchronization, I assume they just forgot to implement it for accessing the NCT668x eSIO." Hopefully this will help to clarify what Martin thinks the problem is.

Quoted from "Speedy-VI"

What Martin (author if HWINFO) suspects is that Aquacomputer is not using a global named mutex when polling this particular sensor

We do this in the correct way. This is working since years without any issues.

Quoted from "sebastian"

Quoted from "Speedy-VI"

What Martin (author if HWINFO) suspects is that Aquacomputer is not using a global named mutex when polling this particular sensor

We do this in the correct way. This is working since years without any issues.

Has it been working for years or have there been polling collisions that no one noticed until va3sd noticed bad data values? You said further up that having 2 programs polling the same sensor can cause "side effects". This is only true if one or both of those programs is not using a global mutex to synchronize the polling requests. HWINFO author Martin has confirmed on his forum that the NCT668x eSIO requires a global mutex to synchronize access to the eSIO with other programs polling the same sensor. Can you please confirm that when you say you do it the correct way that this means you are using a global mutex, because this is the correct way. Martin probably knows more about how to properly poll sensors that just about anyone, so I tend to believe what he says, and the issue va3sd is having appears to be caused by a sensor polling collision. With all due respect, saying oh you can't do that or there may be "side effects" and it's been that way for years is not addressing the problem.

I know that Corsair iCue does not use global mutexes and just assume that they are the only ones polling anything. It's sloppy and lazy, which is about what I expect from Corsair. It is not what I expect from Aquacomputer. A confirmation that you are polling this sensor using a global mutex would clarify that va3sd's problem is not being caused by unsynchronized polling of the eSIO. If you aren't using a global mutex, perhaps you should consider it. Just because no one has noticed polling collisions before does not mean that they are not happening. Since you know AQS users will often have HWINFO running concurrently to import data via shared memory support, this is absolutely something you should address instead of saying we do it the correct way and you can't have 2 programs polling the same sensor. You can, and HWINFO does, and so should AQS. If you are using a global mutex, then please confirm this, and thank you for doing it the correct way. va3sd could then eliminate a sensor polling collision as the cause of his problem. Just my opinion.

Quoted from "Speedy-VI"

This is only true if one or both of those programs is not using a global mutex to synchronize the polling requests.

The aquasuite has a synconized access with hwinfo. The direct hw monitoring is a complete different thing. When you have issues with the Monitoring use only ONE Monitoring software. You can disable the aquasuite Monitoring or dont use hwinfo.

Quoted from "sebastian"

Quoted from "Speedy-VI"

This is only true if one or both of those programs is not using a global mutex to synchronize the polling requests.

The aquasuite has a synconized access with hwinfo. The direct hw monitoring is a complete different thing. When you have issues with the Monitoring use only ONE Monitoring software. You can disable the aquasuite Monitoring or dont use hwinfo.

Let`s imagine: when I use only one monitoring and it is HWINFO if something happened with HWINFO (stopped, did not start or etc) all values which I use in Outputs = 100 it is default status what you guys implemented in your software!
All rules will be triggered.

I do not know does anybody test your software OR any Business Analyst developed this logic, but it is weird. Why nobody check this case?!

So, best way to use AquaSuite - use it with AquaSuite monitoring, it is 100% that nothing stopped and I can get correct values for monitoring.


Summary:
AquaSuite has issue with getting monitoring sensors, HWINFO author confirms it, but HWINFO I use for free, for AquaSuite I pay license every year, so probably I can ask you guys just take a look and fix this issue OR give possibility for users add default values IF there is no monitoring values, it is like workaround for using HWINFO to prevent any issues.

Quoted from "va3sd"

AquaSuite has issue with getting monitoring sensors, HWINFO author confirms it,

I don't think that he confirmed this. He said he thinks that AQS is not using a global mutex to synchronize polling of this particular sensor. Sebastian said they do synchronize polling with HWINFO so maybe something else is causing the issue that va3sd has noticed.
va3sd - If you can monitor this sensor in AQS directly, but want HWINFO running for other reasons, you can disable monitoring of this particular sensor in HWINFO. If it's not polling the sensor, there can't be a collision. In HWINFO you select the sensor then press the Delete key. Have you tried that?

Quoted from "Speedy-VI"

Quoted from "va3sd"

AquaSuite has issue with getting monitoring sensors, HWINFO author confirms it,

I don't think that he confirmed this. He said he thinks that AQS is not using a global mutex to synchronize polling of this particular sensor. Sebastian said they do synchronize polling with HWINFO so maybe something else is causing the issue that va3sd has noticed.
va3sd - If you can monitor this sensor in AQS directly, but want HWINFO running for other reasons, you can disable monitoring of this particular sensor in HWINFO. If it's not polling the sensor, there can't be a collision. In HWINFO you select the sensor then press the Delete key. Have you tried that?

I do not like this tuning, it is workaround, I suppose it should work out of the box without any action from my side.

Quoted from "va3sd"

I do not like this tuning, it is workaround, I suppose it should work out of the box without any action from my side.

Well it's up to you. Sebastian said they do synchronize polling with HWINFO though he never said specifically that they are using a global mutex to do it. So maybe they are or maybe they are using some other method. Whatever they are doing, if the issues you are seeing are the result of polling collisions, disabling polling of that sensor in HWINFO should fix it. Aquasuite is a great program but its not perfect. My setup is relatively simple and I have encountered several bugs. Some I was able to convince them that it was actually a bug and they fixed it. Others seem to come and go and I just deal with them.

I fought with Overview Pages refusing to auto-load for 2 weeks, then one day this just started working again. I have no idea why this stopped working or why it started working again. I have also had some sensor data imported from HWINFO stop working until I reselect the sensor in AQS. Martin (HWINFO author) gave me a shared memory viewer utility that proves that HWINFO is still reporting the data, but AQS stops picking it up for some reason. This only happens occasionally and I have never been able to figure out any pattern to it. Unless the bug is very repeatable, it is difficult to convince the AQS devs that it's a bug and not operator error, so when this happens I just reselect the sensor that stopped reporting. So AQS is not perfect, but it is still the absolute best software out there for controlling cooling components. For RGB I think that iCue offers a lot more features but I would not install iCue to get these features because it is a bloated, buggy mess. AQS does everything I need, and they have added some really powerful features in X.45. You have encountered a bug and reported it. I think that Sebastian has given it all the attention he plans to give it, and it's time to find a work around and move on. Good luck!

Hi, would it be possible to add the possibility of creating other profiles also for the Octo?

Quoted from "Thunder-74"

Hi, would it be possible to add the possibility of creating other profiles also for the Octo?

Not sure what you mean. The Octo already has profiles. Do you mean more profiles?

Quoted from "Speedy-VI"

Quoted from "Thunder-74"

Hi, would it be possible to add the possibility of creating other profiles also for the Octo?

Not sure what you mean. The Octo already has profiles. Do you mean more profiles?

exactly, I would need a fifth profile .. not essential, but useful

Quoted from "Thunder-74"

Quoted from "Speedy-VI"

Quoted from "Thunder-74"

Hi, would it be possible to add the possibility of creating other profiles also for the Octo?

Not sure what you mean. The Octo already has profiles. Do you mean more profiles?

exactly, I would need a fifth profile .. not essential, but useful

Since X.45 you can have more than 4 Global Profiles but the Octo itself is still limited to 4 profiles. I don't know if its possible to add more Octo profiles. It may not be possible due to hardware limitations of the Octo. Someone from Aquacomputer would have to comment on this. I would also like to have more than 4 Octo profiles so will keep an eye on this thread.

i am bumping on that limit, but the real problem is RGB for me. Since the Octo also controls two channels, i'd need more presets, but if it was only controlling fans i wouldn't need more fan curves.
So, going to get a second Fw360 to get rid of RGB control on the octo (and get effect stacking support thanks to the farbwerk).
each preset will be tied to a fan curve on the octo, but pretty much always the same one.. on all profiles.

That's one way to get rid of the Octo limitation, but it costs a few €

Quoted from "Remayz"

i am bumping on that limit, but the real problem is RGB for me. Since the Octo also controls two channels, i'd need more presets, but if it was only controlling fans i wouldn't need more fan curves.
So, going to get a second Fw360 to get rid of RGB control on the octo (and get effect stacking support thanks to the farbwerk).
each preset will be tied to a fan curve on the octo, but pretty much always the same one.. on all profiles.

That's one way to get rid of the Octo limitation, but it costs a few €

Just remember that the 2 Farbwerks360's will not run in sync. I found that out the hard way when I installed a second one. Whether this is a problem depends on what RGB effects you are doing. I had to rethink my Farbwerk360 RGBpx port assignments to get everything I wanted to sync on the same Farbwerk360.

I run an external radiator with four 200mm fans, where under normal load conditions I only want one fan to run.
To make this happen, I generated four virtual software sensor, one for each quarter of the hour, and tied them to four controllers on an octo.

The task would have been simpler had there been a Function that passed through values only when within a designated range.
This would be similar to the existing X=lim(min.max) Limiter, except when the input value is outside the limiter, it returns zero in place of the min/max limit.
One option would be to add a selection to the existing Limiter to return zero when outside the limits.

I could replace 5 decision boxes with a single zero result Limiter box in my virtual software sensor {limited_input.jpg}

Quoted from "Speedy-VI"

Quoted from "Remayz"

i am bumping on that limit, but the real problem is RGB for me. Since the Octo also controls two channels, i'd need more presets, but if it was only controlling fans i wouldn't need more fan curves.
So, going to get a second Fw360 to get rid of RGB control on the octo (and get effect stacking support thanks to the farbwerk).
each preset will be tied to a fan curve on the octo, but pretty much always the same one.. on all profiles.

That's one way to get rid of the Octo limitation, but it costs a few €

Just remember that the 2 Farbwerks360's will not run in sync. I found that out the hard way when I installed a second one. Whether this is a problem depends on what RGB effects you are doing. I had to rethink my Farbwerk360 RGBpx port assignments to get everything I wanted to sync on the same Farbwerk360.

it's OK. I either run a flame effect (out of sync looks better) or RGB puke for when i feel depressed sooo, no worries !

It would help if there were a horizontal bar between Input options in the aquasuite Inputs displayed in the system tray.

• currently {system_tray.jpg}
  
• enhanced {system_tray1.jpg}

Still occasionally seeing the X-axis of displayed log data charts being wildly off.

• added 8 data channels to a Data log {log_data_chart_1.jpg}
  
• added the data to an Analyze data chart (X-axis displays properly) {log_data_chart_2.jpg}
  
• when added to a display page the X-axis is off by decades {log_data_chart_3.jpg}