JowiHue Beta 2.0.4.8

[mikepetro]

mikepetro

Not sure what you mean by groups imported from deCONZ, Are there other JowiHue groups that do show on the status page?
They should show on the status page I suppose, as these devices have the same setup as other devices.... Obviously need more info on this to get it clear here?

Wim

I am sorry, more accurately the "Groups" created in the "WebApp v2.05.66" got imported by Jowihue as devices in Homeseer. These "Group Devices" show under DEVICES in Homeseer, but these devices do not show under STATUS in homeseer.

Your Root/Child fixes seem to have worked for all of the other devices, except for these "JowiHueGroup" devices as none of the groups show under STATUS.

[w.vuyk]

I am sorry, more accurately the "Groups" created in the "WebApp v2.05.66" got imported by Jowihue as devices in Homeseer. These "Group Devices" show under DEVICES in Homeseer, but these devices do not show under STATUS in homeseer.

Your Root/Child fixes seem to have worked for all of the other devices, except for these "JowiHueGroup" devices as none of the groups show under STATUS.

Mike,
I checked here for as much I can handle the status pages - you know I do not like those pages - But I do see the group devices in this page? Although for me missin any usefull data unless I hoover over it....

[Guest]

No errors on 2.0.4.3 ! Seems good

[w.vuyk]

Lol you ware waaaayyyy to fast for me... hehehe Will update the release notes now!

[Guest]

Lol you ware waaaayyyy to fast for me... hehehe Will update the release notes now!

haha that was chance.

[mikepetro]

Well, I found that 4 of the groups were indeed showing up, they were just in a room that was hidden.
I tried deleting the misbehaving group in WebApp, waited until the group went away in Jowiehue, and then recreated it. JowieHue sees the group in Bridge Maintenance but it didnt create the new Devices for the group. How do I force that?

[mikepetro]

Ahhhh, never-mind, I had a filter of devicetype "JowieHueGroup" and now with new beta it looks like it got renamed to "Light Group"

[mikepetro]

Ahhhh, never-mind, I had a filter of devicetype "JowieHueGroup" and now with new beta it looks like it got renamed to "Light Group"

But it didnt rename the old devicetypes.




It shows in status now though. Latest beta 2.0.4.3

[w.vuyk]

You got me wondering there indeed. They should deliver on the status page, could not imagine differently. Glad this got resolved!
As for the new name on groups - those will change on newly created devices only - and show the differentiation for mainly Phiips Hue devices, which uses lightgroup/ luminaires etc.

The old names will not cause issues, the new names might be a bit more clear on their origin.

Wim

[logman]

Is any of you using the HomeSeer mobile app? Are the JowiHue devices showing correctly for you all?

I checked the Android mobile app and everything looks to be working correctly. Here is a screenshot of a light group and of a single bulb. The layout is the way it should be.




--Barry

[Guest]

I know this post wont be liked .. but.. please tell if i'm wrong again.

All test done on mono build 5.0.1.28.

Is it possible the new beta is making the cpu time/load of the hs3 process Itself higher ? If yes, it is sure jowihue beta will never be higher than the hs3 process.

First picture is after I reloaded my ssd clone backup. I did a reboot after this , and it was while we slept. This is with Jowihue non beta . The hs3 process is not doing much . hs3 process cpu time is 18.5 minutes for an Uptime of 14h00
( for the purist : hs3 process pu load of 2.20%)

Second picture is today while we were not home. I did install jowihue beta 2.0.3.3 then I restarted the pc. Hs3 process cpu time is 16.25 minutes but for an uptime of only 6.25 hours.
( for the purist : hs3 process cpu load of 4.33%)

[w.vuyk]

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

[Guest]

Wim .

Will try to reproduce it to validate. Maybe it was just a ''bad '' sample.

Will let it run for the night with the non beta, and will run the beta after pc restart after.

---

I was already sending hs3 memory usage via mqtt to node red using this script .sh script

#!/bin/sh
#

while true
do

t=$( ps axo rss,cmd | grep 'HSConsole.exe --log' | grep -o ^[0-9]*)
t1=$(($t/1024))

mosquitto_pub -h 127.0.0.1 -t HS3/MemUSED -m $t1

 sleep 900
done

For convenience I added theses lines to the script so i get the cpu load % since the process is running too ( for jowihue and hs3)

#!/bin/sh
#

while true
do

t=$( ps axo rss,cmd | grep 'HSConsole.exe --log' | grep -o ^[0-9]*)
b=$( ps axo pcpu,cmd | grep 'HSConsole.exe --log' | grep -o [0-9]\.[0-9] | sed -n '2!p')
c=$( ps axo pcpu,cmd | grep 'HSPI_JowiHue.exe' | grep -o [0-9]\.[0-9] | sed -n '2!p')

t1=$(($t/1024))

mosquitto_pub -h 127.0.0.1 -t HS3/MemUSED -m $t1
mosquitto_pub -h 127.0.0.1 -t HS3/LOAD -m $b
mosquitto_pub -h 127.0.0.1 -t JowiHue/LOAD -m $c


 sleep 900
done

[Guest]

I Think 1h45 is enough, since the % cpu load is near 2.5% for the hs3 process. This is with Jowihue non-beta version.

[Guest]

Here they are for the beta version.