Originally posted by MattL0
View Post
Announcement
Collapse
No announcement yet.
JowiHue Beta 2.0.4.8
Collapse
X
-
Guest
Originally posted by zwolfpack View Post
Its your theory, why do you think it's important? IMO, as long as the CPU has the capacity to handle it, so what? It's not like the gas bill where you pay by the mile.
And yes, of course my system can handle this.
----
This is why I think , in this particular context it is important. if this is not a problem i'll change my point of view and will never check those metric again for Homeseer.
1 a .The value is 4-6 time more than before ( hard to say) but you get what i mean. I think we have to ask ourselves what happened here.
1.b Could that be prevented? if not, then it is what it is .
2.a if every plugin would be at the same value. Is as raspberry pi be able to contain this? would there be any slowdown?
2.b Same a last point but for arm in general .
2.c Same as last point again, but for somebody with many many plugin.
Comment
-
Concern is good... understanding the metric and watching the correct one is also good. As discussed earlier CPU time is not important for diagnosis of performance. If you want to look at CPU performance look at the process usage and then do a cross matrix of process Memory, system IO and IO Wait and see if there's a correlation. Just because a process has CPU TIME is not indicative of a "problem" it just means the process is actually doing something and some do lots of things all the time. Look for sudden spikes such as polling... does the process consume a lot during that period? Maybe things can be fixed within that area (I've done major changes to my plugins in this area with the new releases). Maybe the process is doing a lot of IO to disk or even network which is causing a delay. There's a lot of factors in diagnosis of performance. However the bottom line is simple. Ask one question. Is this a problem affecting this system? If no... well.... no problem.
Comment
-
I'm think CPU load is a more important metric than CPU usage time. In todays world of multi-core hyperthreading CPUs, I don't think usage time is a big deal. Maybe I don't understand how the program calculates CPU usage time, but my understanding is that (in theory) a 16 core 32 thread CPU could show an uptime of 1 hour but a cumulative total of 32 hours of CPU usage time from various processes. Even the Raspberry Pi I think has a quad core processor.
--Barry
Comment
-
Originally posted by MattL0 View Post
1 a .The value is 4-6 time more than before ( hard to say) but you get what i mean. I think we have to ask ourselves what happened here.
1.b Could that be prevented? if not, then it is what it is .
2.a if every plugin would be at the same value. Is as raspberry pi be able to contain this? would there be any slowdown?
2.b Same a last point but for arm in general .
2.c Same as last point again, but for somebody with many many plugin.
#1: process consumed (1.22 min / 68 min uptime ) = 1.8% of total CPU bandwidth
#2: process consumed (6.25 min / 389 min uptime ) = 1.6% of total CPU bandwidth
#3: process consumed (6.57 min / 408 min uptime ) = 1.6% of total CPU bandwidth
Oh the humanity!
Your items (2) are speculative, pretty much nonsense, but arguably also negated by the above analysis.
- Likes 1
Comment
-
Guest
-
Guest
Originally posted by zwolfpack View Post
Do the math. From the three examples you posted above, assuming the process started at bootup,
#1: process consumed (1.22 min / 68 min uptime ) = 1.8% of total CPU bandwidth
#2: process consumed (6.25 min / 389 min uptime ) = 1.6% of total CPU bandwidth
#3: process consumed (6.57 min / 408 min uptime ) = 1.6% of total CPU bandwidth
Oh the humanity!
Your items (2) are speculative, pretty much nonsense, but arguably also negated by the above analysis.
Again I was not saying it was a huge amount of cpu time. I was saying that the the metric was 4-5 x higher than with the non beta .
0.25 min / 68 min = 0,3 % of load
btw this math is why I waited at near 65-68 sec each time to send the picture. if i didn't do this , it would have been very very pointless.
Anyways I think @simplex as a more informative answer.
Comment
-
Guest
w.vuyk Btw ,this is the version file I saw in the .exe
Code:FILEVERSION 2,0,4,1 PRODUCTVERSION 2,0,4,1 FILEFLAGSMASK 0x3F FILEFLAGS 0x0 FILEOS VOS_UNKNOWN | VOS__WINDOWS32 FILETYPE VFT_APP FILESUBTYPE 0x0 { BLOCK "VarFileInfo" { VALUE "Translation", 0x0, 1200 } BLOCK "StringFileInfo" { BLOCK "000004b0" { VALUE "Comments", "Control Zigbee lights, switches and sensors with this plugin for HomeSeer" VALUE "CompanyName", "" VALUE "FileDescription", "HS3 JowiHue Plugin" VALUE "FileVersion", "2.0.4.1" VALUE "InternalName", "HSPI_JowiHue.exe" VALUE "LegalCopyright", "Copyright © 2019 JoWi" VALUE "LegalTrademarks", "" VALUE "OriginalFilename", "HSPI_JowiHue.exe" VALUE "ProductName", "JowiHue" VALUE "ProductVersion", "2.0.4.1" VALUE "Assembly Version", "2.0.4.1" } } }
Comment
-
Originally posted by rprade View PostAfter updating to 2.0.4.2:
Jul-20 8:14:49 AM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object. Jul-20 8:14:49 AM JowiHue Extra info: 0-0-2147-2 Jul-20 8:14:47 AM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object. Jul-20 8:14:47 AM JowiHue Extra info: 0-0-2146-2 Jul-20 8:14:46 AM JowiHue Created new colourtemperature device for Grabrail RGB Jul-20 8:14:46 AM JowiHue Devices added for light Grabrail RGB Jul-20 8:14:46 AM JowiHue Created new Hue devices for Grabrail RGB Jul-20 8:14:46 AM JowiHue CT device has been removed for Grabrail White Jul-20 8:14:46 AM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object. It all seems to be working. Unfortunately I am off to work now, I’ll look at it later and see if there are any problemsJul-20 8:14:46 AM JowiHue Extra info: 0-0-2145-2
I did not really mention it in the change list, but there is a change for RGBW strips in the plugin, which is really a logical part of the conversion. The White part of the lightstrips was always held in a seperate device before. But with the new setup that is based on the uniqueid's of the devices, it will be automatically join the parent setup of the RGB part of the strip. Which is good, and logical. I have a Dresden RGBW strip here also, and it is working for me, but it seems to throw errors for you.... could you send me a detailed trace (to jowihue at ziggo dot nl ) so I can have a closer look at it?
Wim-- Wim
Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData
1210 devices/features ---- 392 events ----- 40 scripts
Comment
-
Originally posted by logman View PostFYI, i downloaded and installed version 2.0.4.2 and everything seems to be working normally. Only issue is the plugin list still shows 2.0.4.1 as the installed plugin, but I believe this is just a grammatical error.
--Barry
Barry,
My bad. I had been doing the changes and after all was found good, I changed the version, and submitted the new beta. But..... this old man had forgotten to compliel the plugin once more to make sure the new version was landed in the plugin..
You have the changes, but the version is not up to date. I will correct this later today by submitting a new beta - minor changes though
Wim-- Wim
Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData
1210 devices/features ---- 392 events ----- 40 scripts
Comment
-
Originally posted by kenm View PostConfirmed this was self-induced. An HS restart got the plugin enable/disable back and killing off the ha-bridge emulator I had running on a Pi resolved the crash loop.
Have you heard the one about the man who goes to the doctor and says "Doctor, doctor, it hurts when I do this." and the doctor replies "then stop doing that.".
Ken
I thought I had some catches done already (with I think?) for the ha bridge. Could you 'self-induce' this again with the detailed trace and trace to log options in the plugin enabled? Then send the log (JowiHue.log from the logs directory) to jowihue at ziggo dot nl? Just becasue I am the doctor who says "Try again?"
Wim-- Wim
Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData
1210 devices/features ---- 392 events ----- 40 scripts
Comment
-
Originally posted by MattL0 View Post
I think this polling is only for the philips hue bridge (I asked this question myself to Wim). Not deconz (websocket).
But here is mine. I have set it to 30 sec because I thought it was a sort of security check for being sure the data was there , before I found it was meaningless for my setup( I have deconz)
Thanks all for the discussion! I think it is good to review how a plugin is behaving as this (for me at least) is always one of the worries. The plugin can behave nice on one system and go beyond borders on another system. This plugin is polling and that has been worrying me always so far.
But polling is enforced by the 'standard' helas.
Philips Hue bridges do not present any information outside the bridge by itself, there is no websocket like structure implemented, so the only way is to use polling. This part of polling can be configured in the configuration page of the plugin. The deCONZ gateway starts off with this same parameter, but goes its own way after the conection has been set ("Refresh bridge RaspBee Wim set to 30 seconds after establishing direct connection")
DeConz has implemented a (non standard) Websocket structure, wich enabled 'direct' updating of devices. But the plugin still does also poll the deCONZ gateway. To be guaranteed the plugin is really up to date with its devices,. It does this with a frequency of once per 30 seconds.
For the polling part you should see a network raise and a subsequent cpu raise of a few milliseconds, where the plugin checks and updates devices with the new information retreived. This was already in the production version of the plugin and has not changed in this beta. For the network this should be ca. 50 Kb per bridge?
For the new beta really a LOT of code has changed under the hood, but focussed on the device structures... It took me two months for all changes to be done and trust myself.
With these changes device handling has been thoroughly changed, which I think should not take much CPU, but one can never be sure....
Most important changes regarding CPU should the folowing few:- recalculations for xy values of lights. In the old version it was done twice or even triplle times in some situations. Now it is only done once on the last possible moment. this should - if seen.... lower CPU and response time...
- Group handling, when a group device is updated by event or action on device management page the check for update on groups is enforced. Depending on the freuency of such updates it could increase CPU usage a bit
- The way lights are controlled has been cleaned - I removed some code that was not really needed anymore - this should lower CPU and improve performance a bit.
- Sensor checking has been changed, to work with the new device structure. This resulted in removing quite some code. which again should be in favor of the CPU
I myself think if the plugin does not use a lot of CPU % on average, that total CPU time should not be much of a worry, unless it starts to beat the HS3 usage - which is the main ship after all?
We will keep an eye on it, but for now I think we can leave it this way?-- Wim
Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData
1210 devices/features ---- 392 events ----- 40 scripts
Comment
-
Originally posted by w.vuyk View Post
kenm
I thought I had some catches done already (with I think?) for the ha bridge. Could you 'self-induce' this again with the detailed trace and trace to log options in the plugin enabled? Then send the log (JowiHue.log from the logs directory) to jowihue at ziggo dot nl? Just becasue I am the doctor who says "Try again?"
Wim"if I have seen further [than others], it is by standing on the shoulders of giants." --Sir Isaac Newton (1675)
Comment
-
Originally posted by w.vuyk View Post
Randy,
I did not really mention it in the change list, but there is a change for RGBW strips in the plugin, which is really a logical part of the conversion. The White part of the lightstrips was always held in a seperate device before. But with the new setup that is based on the uniqueid's of the devices, it will be automatically join the parent setup of the RGB part of the strip. Which is good, and logical. I have a Dresden RGBW strip here also, and it is working for me, but it seems to throw errors for you.... could you send me a detailed trace (to jowihue at ziggo dot nl ) so I can have a closer look at it?
Wim
The log entries at startup are the same each time:
Jul-21 2:44:24 PM JowiHue Devices added for light Grabrail RGB
Jul-21 2:44:24 PM JowiHue Created new colourtemperature device for Grabrail RGB
Jul-21 2:44:24 PM JowiHue Created new Hue devices for Grabrail RGB
Jul-21 2:44:24 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:44:24 PM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.
Jul-21 2:44:24 PM JowiHue Extra info: 0-0-2197-2
Jul-21 2:44:24 PM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.
Jul-21 2:44:24 PM JowiHue Extra info: 0-0-2196-2
Jul-21 2:44:24 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Jul-21 2:44:24 PM JowiHue Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.
Jul-21 2:44:24 PM JowiHue Extra info: 0-0-2195-2
These two log entries repeat every 10 minutes:
Jul-21 2:40:03 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:40:03 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Jul-21 2:30:03 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:30:03 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Jul-21 2:20:03 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:20:03 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Jul-21 2:10:03 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:10:03 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Jul-21 2:00:03 PM JowiHue CT device has been removed for Grabrail White
Jul-21 2:00:03 PM JowiHue Color devices (hue and Sat) have been removed for Grabrail White
Trace log sent to your email.
I will add that while I understand the changes, I use two different LED strips, one with white LEDs and one woth warm white LEDs. This requires me to control the white channel separately, since neither was correct using pure CT settings.HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon
Comment
-
Guest
Originally posted by w.vuyk View Post
zwolfpack logman simplextech
Thanks all for the discussion! I think it is good to review how a plugin is behaving as this (for me at least) is always one of the worries. The plugin can behave nice on one system and go beyond borders on another system. This plugin is polling and that has been worrying me always so far.
But polling is enforced by the 'standard' helas.
Philips Hue bridges do not present any information outside the bridge by itself, there is no websocket like structure implemented, so the only way is to use polling. This part of polling can be configured in the configuration page of the plugin. The deCONZ gateway starts off with this same parameter, but goes its own way after the conection has been set ("Refresh bridge RaspBee Wim set to 30 seconds after establishing direct connection")
DeConz has implemented a (non standard) Websocket structure, wich enabled 'direct' updating of devices. But the plugin still does also poll the deCONZ gateway. To be guaranteed the plugin is really up to date with its devices,. It does this with a frequency of once per 30 seconds.
For the polling part you should see a network raise and a subsequent cpu raise of a few milliseconds, where the plugin checks and updates devices with the new information retreived. This was already in the production version of the plugin and has not changed in this beta. For the network this should be ca. 50 Kb per bridge?
For the new beta really a LOT of code has changed under the hood, but focussed on the device structures... It took me two months for all changes to be done and trust myself.
With these changes device handling has been thoroughly changed, which I think should not take much CPU, but one can never be sure....
Most important changes regarding CPU should the folowing few:- recalculations for xy values of lights. In the old version it was done twice or even triplle times in some situations. Now it is only done once on the last possible moment. this should - if seen.... lower CPU and response time...
- Group handling, when a group device is updated by event or action on device management page the check for update on groups is enforced. Depending on the freuency of such updates it could increase CPU usage a bit
- The way lights are controlled has been cleaned - I removed some code that was not really needed anymore - this should lower CPU and improve performance a bit.
- Sensor checking has been changed, to work with the new device structure. This resulted in removing quite some code. which again should be in favor of the CPU
I myself think if the plugin does not use a lot of CPU % on average, that total CPU time should not be much of a worry, unless it starts to beat the HS3 usage - which is the main ship after all?
We will keep an eye on it, but for now I think we can leave it this way?
Are we near the final release?
Comment
Comment