JowiHue Beta 2.0.4.8

[Guest]

Matthieu,

JowiHue is never really calling HS3 directly other then updating devices based on state changes of lights and sensors. This part has not changed at all. Other then that it is being called by HS3 and will then check and/or execute the event or device actions.As far I can think of, there has not much been changed here. All I can do is check few steps here in the code that might influence this, but I have no ideas where to look for really, I did not build loops I think?

Wim

After watching htop for some time I can say that when there is a cpu spike in jowihue process (now watching the beta) there is one in the hs3 process too. Theses 3 pictures are just an exemple, and I could produce two graph of that to better correlate theses... but this is time consuming. Maybe another day

[Guest]

FIW,

Mcsmqtt plugin was also putting high load on the hs3 process .

Since I have deactivated it ( My system is as functional as before : 1- I now use hs3 json api to receive payload from node red and else. 2 - I use .sh scripts to send data to node red (or else) via mqtt ) , my cpu time for a one day period have dropped from 72 min to 36 min! This is half the load , with the exact same fonction as before! .
+ Mcsmqtt was making my hs3 process memory leaking. Now it stopped leaking! So yes a plugin can influence the hs3 process ( In various way)

Your plugin seems to not leak the hs3 memory process on mono 5.18.1.28 (will have to wait a couple of days to confirm). But on mono 6.0.0.313 it does (beta and not beta, I quoted you on that on another thread, but that’s another subject (I think?)).

[w.vuyk]

A CPU spike in the plugin probably means the plugin is doing its job getting information from the gateways. I am pretty sure you will see the same spike in network usage, as it is getting data? Then during that same spike it is updating HS devices, so yes, HS3 will also show some activity? Is that bad?

I am at loss what you want me to do? Is the system unresponsive now? Thje plugin has changed considerable, so maybe it behaves a bit different. I do not see the issue here?

Wim

[Guest]

It is as you feels it , I just reported the issue.
( see posts 71, 74 and 75 ) .

No i didn’t see any lags on my system, and didn’t test it more than 5 hours I think.

, the point was not the spike ( this was an exemple only to respond to your comments) The point was the load ( it adds about the sane as mcsmqtt Now). And if you addition the load of the Jowihue beta , and the load it ads to hs3 process , that does go beyond the load of hs3 process before the beta came out .
.yes it nows goes beyond the ship.


So I do not think it does behave a bit differently, but very differently.


Thanks,

Matt.

[Guest]

haww OK.

I missed something. NO there is nothing you can do for it, for the beta . This is just something to be aware of , and something you could try to get to ( old performance value on the plugin and the hs3 process ), in the future.

Just be aware that the plugin add something like 1300 % ( that's an estimate) of cpu usage versus before ( accounting the jowihue process and the hs3 process bump), for to be somewhat as functional as before.

[w.vuyk]

Matthieu,

What are the differences you are testing for the new beta? Are you using events that use the "if any device in group is on/off" for the beta and you did not have this in the production version? Do you have different event actions in the beta compared to the production version? Or devices? What are really the changes you did on the beta image compared to the production version? There are endless situations possible for the differences you are mentioning and there is no way I can see that here. The plugin has changed, sorry for that. It might change in behaviour in time.

I have double checked the plugins behaviour - under Windows here though with you comparison on totals of hs3 time and JowiHue time, both running for more time then you let it run so far, and if you lok at hs3 as 100% running time, JowiHue is 2% compared to that. And this on an average CPU (which is ofcourse only relative) of 7% of all running processes.
Do I feel alerted? Not really here. 40 hours HS3 to 1 hour JowiHue....

Can I relate to the Linux issue you see? Not at all, I am a Linux nitwit, have a hate/love relation with it. Setting up a linux system here works, but making it run reliable takes me days. I cannot argue with you if it is good or bad, But I do not think using more cpu time with a still consistent low cpu average is really an issue, but only changed behaviour, maybe because of Event differences/device differences? I just do not know, and even less I can guess why Linux gets more nervous (it always does when I even look at it )

Wim

[Guest]

i can assure you both config were exactly the same.

. So your hs3 process has a load of 4% , but hard to say for jowihue beta ( and even hs3 since you probably restarted jowihue plugin) You could try a system reboot to get better stats .. but anyways nobody seems to care lol. Hope that will get somewhat as before in the long run

.Thanks for your feedbacks!

[w.vuyk]

Nope, this is an image of the beta running after a reboot of the system. I did not really restart the plugin in between....to be honest, I did not yet upgrade the production system yet I am on 2.0.4.2 --- with the reported wrong version .....

[Guest]

Nope, this is an image of the beta running after a reboot of the system. I did not really restart the plugin in between....to be honest, I did not yet upgrade the production system yet I am on 2.0.4.2 --- with the reported wrong version .....

Aww lol

Me too i am on non beta. (realoded my backup). Then i guess you'll see some change in those stats when you load the beta version on prod as i did ( that was the point lol).

[w.vuyk]

Sorry, Matthieu, you need to reread the message

Nope, this is an image of the beta running after a reboot of the system. I did not really restart the plugin in between....to be honest, I did not yet upgrade the production system yet I am on 2.0.4.2 --- with the reported wrong version .....

I did not upgrade to the latest beta......

[Guest]

Yes i did correctly read. i know you are NOT on the beta.

So you can't test how much the new beta impact the cpu load of hs3 process and JOwihue plugin process right now. When you will load the new beta on your prod you will be able to tell the diff. This is why I said: That was the point of the whole conversation. The difference in cpu load of the NON-beta versus the BETA.

Jowhue beta ( taking into account the higher load it makes on hs3 process and the higher load it has on the jowhue process) adds 1300% ( 13 times more ) cpu load versus non-beta .

[w.vuyk]

Reread again, I am on beta 2.0.4.2 with the production, not on 2.0.4.3, and it is not showing the issue you are seeing,You started seeing the changes aready at 2.0.4.1,,,,, So we surely do not see this issue on Windows.....

[Guest]

Sorry wim. Got what you wrote now .

[bdickhaus]

I am seeing increased CPU utilization also, but it doesn't seem to be causing any performance issues. Ubuntu 18.04 and Mono 5.20.1 at the moment.

[Guest]

I have to say first : this is not an apple to apple comparison. It would not be fair to compare them like that. A plugin must satisfy every customer. My approach just need to satisfy myself and my setup.


----

I have ( used this package to get the WS connection for status updates https://www.npmjs.com/package/node-red-contrib-deconz, used json hs3 api to receive the values to a bunch of virtual devices i needed to create ( and yes i did create a root device for any of them), and used the http put capability of the big5 plugin to control/ send command directly to deCONZ api ( but for devices that needs two ways (control + value updates) i have set a ''cannot rerun this event for 1 sec)), used another approach to communicated with deconz.
For now i get the exact same functionality.

I even think I would be able to transfer my system to an arm board. hs3 has a load of 1.2 % on the system, which is nothing,and the memory leak seems to be gone. if it is not, it is very slow (so I do not care).

Will continue to use the plugin at my mother house, because the plugin is very user friendly, And i wont pass the time it takes, there ( at my mother house), as I did on my own setup.