Announcement

Collapse
No announcement yet.

JowiHue Beta 2.0.4.8

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    Originally posted by MattL0 View Post
    Isnt that important ?
    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.

    Comment


      #47
      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.
      Of course it is mine... but maybe it is for other point of view too , but who care that point. :P. I i am wrong i will admit it and change my point of view. Exactly like I changed my point of view on the cpu time Homeseer is consuming . ( Btw , simplextech made me change my mind of this, on another topic...like 8 months ago ?)

      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


        #48
        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


          #49
          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


            #50
            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.
            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.

            Comment


              #51
              Thanks guys. The ll'l stop to chek that metric then !

              Comment


                #52
                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.
                Yes it was speculative I do not have a pi to test. Yes all the item were speculative , so what? lol.

                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


                  #53
                  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


                    #54
                    Originally posted by rprade View Post
                    After 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.
                    Jul-20 8:14:46 AM JowiHue Extra info: 0-0-2145-2
                    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 problems
                    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
                    -- 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


                      #55
                      Originally posted by logman View Post
                      FYI, 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.

                      Click image for larger version

Name:	jowihue.png
Views:	254
Size:	31.2 KB
ID:	1316764

                      --Barry
                      logman

                      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


                        #56
                        Originally posted by kenm View Post
                        Confirmed 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
                        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
                        -- 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


                          #57
                          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)
                          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
                          In total I would expect similar or slightly improved response and CPU usage to be more or less the same.

                          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


                            #58
                            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
                            Logfile sent via email. I wasn't really using the ha-bridge so I just disabled it for now. It was a leftover from experimenting with lighting scenes in combination with the Logitech Harmony Hub.
                            "if I have seen further [than others], it is by standing on the shoulders of giants." --Sir Isaac Newton (1675)

                            Comment


                              #59
                              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 errors are the same at each startup. Here are the devices, it is a mess.

                              Click image for larger version

Name:	Capture.PNG
Views:	172
Size:	496.2 KB
ID:	1317059
                              Click image for larger version

Name:	Capture1.PNG
Views:	131
Size:	86.4 KB
ID:	1317060
                              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


                                #60
                                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
                                In total I would expect similar or slightly improved response and CPU usage to be more or less the same.

                                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?
                                Thank for all these explanation. This is a very nice update .

                                Are we near the final release?

                                Comment

                                Working...
                                X