I’m not sure to be honest. I’m not talking about the same as Thomas. Within vs code I can install an openHAB plugin. After that, and with each start of vs code, I can see that vs code installs an vs code server ?on the openHAB? I assume that this is a component needed to get the states and items etc.
But I’m not in the details here
Just reviewed the GitHub page of the openHAB-vscode extension. This is how it’s really named. Regarding to that it has been developed for OH2.x. Maybe it’s a compatibility issue between this extension and OH itself
@HuberDe just to be clear: I shall not do any more work on this topic until you can give me clear evidence that there is something in the Hue binding that needs to be fixed.
Now you are confusing me.
Are you using code-server, installed on your openHAB server ad in my linked post, or do you use VS Code installen on a different machine, accessing config files through a samba share ?
Please give some more informations, as it makes a difference.
Ok. To make that more clear.
So I connect the Pi to edit files and a few hours after that, the motion sensors stop to work
Ok, so nothing I mentioned should be relevant here, as you did not install anything on your openHAB server.
Not sure what the extension is doing. I’m user only. I understood that this is installing something on the Pi/OH side, too
No, the extension is installed into your VS Code and just gives, after proper config, access to the language server and your config files. Nothing installed on openHAB side.
Ok. But then I’m wondering why it’s a difference if I’m using the extension or not. We will see. I uninstalled it yesterday and currently it’s still running
Good morning guys,
I just placed one of the sensors on my desk.
If I move my hand in front of it, I immediately get a reaction from the corresponding MOVE and LUX items.
LUX then updates itself after a few seconds when I remove my hand. MOVE switches back after the dead time.
Very nice, as expected.
I then removed 5 excess HUE items in the items file (separated from channel) that were only used to display the original brightness values and saved the file. (Via VS code)
After that the system was totally messed up. The sensor initially stopped responding and only reported the temperature. LUX and MOVE did not come at all, or with a very long delay. Partly then in blocks, but not online.
Then appeared in the log: [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber ‘org.openhab.core.internal.items.ItemUpdater@eabf7b’ takes more than 5000ms.
Just as I was about to dive deeper, the system reset itself.
Now the sensor is responding as expected again.
Here is the log from the moment the Itemsfile is reloaded:
Eventlog.txt (477.3 KB)
Edit:
OK, I tryed this two more times connecting and disconnecting the above items.
This times everything works fine, and the sensor reacts immediately
as he should… 
Regards
Thomas
That means something is blocking the OH core. Perhaps you addon, or samba file access or whatever. Who knows?
More interesting is that the binding is reporting Error (grouped_motion) … this is a new feature that was added to Hue firmware in the last 1…2 months. So it is possible that this may be the real cause of the problem. And that would be absolutely nothing to do with VS plugins / code server / samba file access.
I already reported my issue in July. So not a new topic…
Indeed. In a forthcoming PR I will recognise the grouped_motion resource type. But it is just a cosmetic change: the default action for unrecognised resources was ‘do nothing’ and now those resources are recognised the action will be … ‘do nothing’. 
The only difference is that you will not see the warning message in the log any more.
Facit: this is NOT the cause of your problem.
I do indeed have a problem with latency.
Sometimes(!) actions are executed with a delay. Example: The light in the stairwell, the HUE Strip lights up immediately, the ZWAVE Strip follows a few seconds later.
I have also noticed that sometimes several rules are in running status for minutes, although only a single command needs to be executed. I have not yet been able to pinpoint the cause.
The CPU load is low…
But I don’t think this has anything to do with the problem with the missing motion events.
I have already considered whether the SDCard is defective and there are sometimes delays when writing the log files.
That might explain this morning’s behavior.
Just wanna let you know, that I don’t use groups or scenes in HUE app.
Grouped motion is a new construct that (optionally) allows more than one motion detector to switch on lights in a single room/zone.
Guys, I still have no idea about what could be your problem.
You seem to be implying that 1) status events for some (motion) channels cease to arrive, 2) status events for other channels continue to arrive, and 3) commands to all channels continue to work.
As mentioned before, the binding relies on just ONE single HTTP/2 channel for ALL traffic between OH and the Hue Bridge in both directions. And as mentioned before, I cannot imagine any scenario where some traffic would pass over the HTTP/2 channel, yet other traffic would cease to pass.
{ Actually to be fair, (as I am a software engineer), I can imagine just one hypothetical scenario whereby a firewall state based packet interceptor, either on the OH IP protocol stack, or on your router, might be maliciously “stealing” just the packets for the event traffic for just the motion sensors, and otherwise letting everything else pass. This would be exceedingly difficult since both TCP itself, and HTTP/2 on top, have quite robust mechanisms for detecting and resending dropped packets. }
Anyway, the following are some things whereby you can check in logs if the single HTTP/2 channel is alive or not. And if you do not see such messages then that would be some signal that the HTTP/2 channel might be down.
Every fiveminutes you should see the following in your log
2024-12-15 10:52:29.536 [DEBUG] [.hue.internal.connection.Clip2Bridge] - checkAlive()
2024-12-15 10:52:29.538 [DEBUG] [.hue.internal.connection.Clip2Bridge] - checkAliveOk()
Every ten minutes you should see the following in your log (note: both the GET requests and the respective HTTP/2 200 responses)
2024-12-15 10:47:29.158 [TRACE] [.hue.internal.connection.Clip2Bridge] - GET https://192.168.1.108/clip/v2/resource/room HTTP/2
2024-12-15 10:47:29.179 [TRACE] [.hue.internal.connection.Clip2Bridge] - HTTP/2 200 (Content-Type: application/json) << ...
2024-12-15 10:47:29.158 [TRACE] [.hue.internal.connection.Clip2Bridge] - GET https://192.168.1.108/clip/v2/resource/zone HTTP/2
2024-12-15 10:47:29.179 [TRACE] [.hue.internal.connection.Clip2Bridge] - HTTP/2 200 (Content-Type: application/json) << ...
2024-12-15 10:47:29.158 [TRACE] [.hue.internal.connection.Clip2Bridge] - GET https://192.168.1.108/clip/v2/resource/device HTTP/2
2024-12-15 10:47:29.179 [TRACE] [.hue.internal.connection.Clip2Bridge] - HTTP/2 200 (Content-Type: application/json) << ...
Hi Andrew,
My OH is working without any issue since I uninstalled the VS Code OpenHAB extension earlier this week. I will currently let it run as it, because the WAF is meanwhile really low if each half day a lot of lights in the house aren’t working 
and I trigger a lot of my lights with the motion sensors, without having switches for them…
Hopefully Thomas follows that issue if he can’t get rid of it on another way like me. Maybe I can dig more into that in the christmas days when there is more free time…
Denis
PS it is worth mentioning that in your log with duration 17 minutes, there were 21 instances of 5000ms delay reported i.e. 1.75 minutes! Or 10% of your run time!! And it is probably more than 10% since a) delays more than 5000ms, and b) significant delays less than 5000ms, are not logged!
Thank God this is not the normal behavior of my system.
So far, OH has also been running without any particular incidents.
However, I was not online yesterday with doing any changes.
My last adjustment was to remove Android Google TV things that were not online/connected and were waiting to be paired. I left a paired media player in the system.
I continue to use VS Code and have no problems with it.
Except, thanks to Andrerw for the new problem :), that I noticed that the Things in the sidebar cannot be read. The items are coming. I hadn’t even noticed/used the sidebar before, so I didn’t even notice the error. Obviously OH does not accept the token… I’ll see when I can look into this.
Anyway, I’ll keep an eye on the system for a few more days and only then will I reintegrate the other media players and see if this results in HUE errors again.
Regards
Thomas