![]() ![]() The new way is really MUCH simpler and I have posted a minimal example on how to get to the data here: I also announced that change long before it went live and also shared the BETA version for quite some time before 6.0.01 came out. The reason is that we need it to communicate with the sidebar gadget and the pipe communication is a one-to-one connection, so the old Rainmeter plugin implementation was really an 'abuse' of this channel (Leo did that with our blessing though and with information that were not publicly available).īut we have to be able to modify this API as this is tied to internal data structures that are subject to change if we need to move things around for adding new stuff to the gadget.īecause we wanted to offer some stable and documented API, I set out to do just that and now we are free to change the pipe struct as required while at the same time can offer a stable and extensible interface to get to all internal data in a standardized way. All those give me the value shown in OHM with Read HDD sensors.īut, like I said, disable that and it gives me the CPU-clockspeed, CPU-Fanspeed and CPU VCore voltage.Įverything show up correctly in OHM, but the plugin gives me the wrong values.Sorry for the requirement to break the Pipe API, but this was never intended to be used for anything other than internal communication and was also not documented. If I after disableing HDD Sensors restar OHM, the measures give me: AVCC voltage, (what seems to be) CPU max temp, CPU total load as a number. If I now restart rainmeter (and by that reloading the plugin) everything goes back to normal. Now I choose to read the HDD sensors (just for testing) I get: CPU core #5 temp, CPU core #2 temp and Sys temp. Restart rainmeter and it gets the right values. ![]() So, the conclusion is that if you change what should be read by OHM, you have to restart rainmeter. The plugin works by doing this:ġa) read all the hardware and sensor configurations from OHMġb) repeat 1a) until the same number of sensors has been read 3 times in a row (this handles OHM's finite startup and hardware/sensor discovery time). When in mode 1), it requires a lot of calls to OHM and searches for pairing up the hardware and sensors. ![]() I was worried that if you do this every time the measure is updated, it will take forever so it switches to mode 2) when it can and just reads the sensor values. But - this assumes that once you start OHM up, the set of sensors and the order it reports them is fixed. Clearly this is where your problem appears as they aren't fixed. I think the best solution which will fix the problem and still be efficient is to have the plugin see if it gets a different number of sensor values than it expects in 2) and if that occurs, trigger a "reset" and go back to mode 1) to refresh the sensor list. I can also put valid ranges on the sensor values (Load should never be above 100, Temperatures should never be above 500, etc) and if those are violated (which would indicate the wrong sensor is being read), also trigger a mode 1) refresh. Looks like there are some issues that need looking into. The skins made with the plugin seem to work fine in and of themselves. ![]() Everything displays as it should and it's very nice. If any skin using it is running, then Rainmeter becomes a bit weird and unstable. Rmskin file, I either get a crash of Rainmeter (if the new skin has a Lua script) or a behavior where the new skin is loaded but does not display unless I refresh the skin. Rainmeter open hardware monitor plugin skin#. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |