JowiHue Beta 2.0.4.8

[randy]

I installed the latest last night and got these errors at startup:

Jul-20 7:59:22 AM

JowiHue

Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.

Jul-20 7:59:22 AM

JowiHue

Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.

Jul-20 7:59:22 AM

JowiHue

Error: (HSEvent)::Error running config change:Object reference not set to an instance of an object.

Jul-20 7:59:19 AM

JowiHue

Error: (InitDevices)::Object reference not set to an instance of an object.

Jul-20 7:59:19 AM

JowiHue

Error: (InitDevices)::Error while scanning device Grabrail RGB (root) Object reference not set to an instance of an object.

The bottom error is referencing a Dresden RGBW module. I’ll install the new beta from this morning later today.

[randy]

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

[logman]

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.



--Barry

[Guest]

Same here . Don’t know if iI am on 2.4.1 or 2.4.2

[kenm]

Updated to 2.0.4.2 and all seemed to go well for a while and then I started getting into a crash loop where the plugin was disconnecting and restarting over and over again. This "may" have been self-induced since I tried to add an ha-bridge emulated bridge not long after updating to 2.0.4.2.

For now, I disabled the plugin but then things got a little weird. The Enable/Disable option now says "Loaded Remotely" with no way to re-enable the plugin.

[kenm]

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

[Guest]

here is another shot :

first picture : old jowi plugin

second picture : new beta ( if I have the time)

Here is another image with jowihue beta loaded .

the cpu+ time is like 4-5 time higher.

[logman]

I'm not seeing any increase in CPU load. If anything, I think the beta is using less CPU that the production version does. I'm on Windows Server 2016. Wonder if this is a mono issue?

--Barry

[zwolfpack]

Here is another image with jowihue beta loaded .

the cpu+ time is like 4-5 time higher.

I think you're creatively (mis)interpreting the htop readout. Per the screen shot, The JowiHue.exe process CPU percentage at that moment is 0%. System uptime is approx. 1 hour 8 minutes, and during that time JowiHue has accumulated 1 minute 13 seconds + change of CPU time. This hardly seems excessive. Most likely the process was (gasp) doing stuff that you told it to...

[Guest]

I think you're creatively (mis)interpreting the htop readout. Per the screen shot, The JowiHue.exe process CPU percentage at that moment is 0%. System uptime is approx. 1 hour 8 minutes, and during that time JowiHue has accumulated 1 minute 13 seconds + change of CPU time. This hardly seems excessive. Most likely the process was (gasp) doing stuff that you told it to...

I understand that, I am just saying the the process ( beta) is doing more stuff than the non beta .

Just now, it is at 6 min. But before the beta it would have been at 1-1.5 minutes.
Isnt that important ?

[simplextech]

Yes... it's important... it means the plugin has actually done something for a cumulative 6 minutes of the total runtime of the process.

[Guest]

I'm not seeing any increase in CPU load. If anything, I think the beta is using less CPU that the production version does. I'm on Windows Server 2016. Wonder if this is a mono issue?

--Barry

I just think that the metric is not there in windows task manager. ( how much time the process pass on the cpu since it is on)

[logman]

I just think that the metric is not there in windows task manager. ( how much time the process pass on the cpu since it is on)

Have you changed the polling frequency of the plugin? I have mine set to poll every 3 seconds. Any plugin that is set to poll multiple times per minute is going to rack up more CPU time than a non-polling plugin. I'm ok with that though because I want my lights to be responsive and quickly sync/update back to HS,

--Barry

[Guest]

Have you changed the polling frequency of the plugin? I have mine set to poll every 3 seconds. Any plugin that is set to poll multiple times per minute is going to rack up more CPU time than a non-polling plugin. I'm ok with that though because I want my lights to be responsive and quickly sync/update back to HS,

--Barry

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)

[simplextech]

I think this polling is only for the philipis hue bridge. Not deconz (websocket)

A WebSocket is an active process. The client side is responding to and processing a ping/pong from server as well as receiving/processing messages as they occur. So it uses CPU time.