Closed maskedfighter closed 5 years ago
That error is not related to entertainment but to ssdp discover process that probably received an unexpected search string. What types of lights are you using in entertainment and what PC application?
For now, i use an esp8266 controlled rgb-cct led stripe. As far as i remember, entertainment did work a while ago, but then i reinstalled the emulator and since then, the light stays green and doesnt flash when tested in the official hue enternainment-setup. I tried hue sync on windows pc, it does connect to the bridge, but no function on the stripe. Debug shows nothing though.
i have the same problem since i flashed light version 3.0 for the ws2812b strips. This version somehow is not working anymore with hue entertainment. The light positioning screen is working but the fading test does not. Also music and tv sync is broken. Colors are not changing
edit: tested it again with version 2 and now it is also not working.
edit: reverted even further back to 215bc4a still not working.
I can confirm that it isn't working here either. ESP8266-based Using a strip based on WS2812b
Changing colors via the Hue app's color wheel works great, but testing the lights in the entertainment setup shows no change in color. They simply stay green the whole time. Hue Sync doesn't work at all due to the above.
When running the emulator in debug mode, as soon as I get to the configuration stage on the app where the lights are tested and color switched, the emulator starts spamming " Entertainment Service was syncing and has timed out, stopping server and clearing state" several times per second. Looking at the code, it seems there's a general exception handler, and the author has assumed it to only happen if a network timeout has occurred, but we might be faced with another exception. By the code, the application doesn't know to do anything else but kill the entertainment server and restart it, causing a loop.
except Exception: #Assuming the only exception is a network timeout, please don't scream at me
if syncing: #Reset sync status and kill relay service
logging.info("Entertainment Service was syncing and has timed out, stopping server and clearing state")
Popen(["killall", "entertainment-srv"])```
If you downgrade the light to previews version it is working? You upgraded to new version or is the first flash of this light?
@mariusmotea it is also the case if i erase the flash and reflash 2.0 versions. Tried some older version always the same. The strange thing is, before i reflashed the wemos' to 3.0 yesterday all was working fine. Afterwards it's not working any more even after flashing back to 2.0 again.
Nor the diyhue bridge nor the app got an update yesterday so this is very strange.
I will try to replicate in a few hours.
I will try to replicate in a few hours.
I can try downgrading although this issue seems to lie with entertainment on the emulator side rather than the lights, or so it seems.
I've modified the code to print out any exception, and it's timing out on the service the entire time ("timed out"). When attempting to run the setup for Entertainment via the Hue app, it instead gives
[Errno -2] Name or service not known
Edit:
The problem lies ultimately in the code that gets the IP for the lights.
By manually setting the IP of the lights here, it works to setup those specific lights:
sock.sendto(udpmsg, (ip, 2100))
The function related to the above returns IP + port (IP:80) but it needs only the IP so it can send to port 2100
QnD fix is to add
ip = ip.split(":")[0]
to the line just above
sock.sendto(udpmsg, (ip, 2100))
@JohnBFrm maybe make a pullrequest with your fix? or is this just a quick "hack"
@JohnBFrm maybe make a pullrequest with your fix? or is this just a quick "hack"
It might be good to review what has changed first, as the problem could be potentially fixed higher up. The above function is passed the address of the lights from HueEmulator3.py, when it creates a new threads and calls entertainmentService, passing it lights_address from config.json, which in turns has the address of the lights including the port (":80").
If this has changed recently, it might've been overlooked.
Also, @mariusmotea is there a reason for having a socket timeout in entertainment.py? We're waiting on UDP data as a listener, I cannot see the reason for the timeout, but it is causing it to quietly throw a timeout exception. It should work fine in all cases if set to None.
If i'm not wrong the timeout is usefull there because once the entertainment app stop the broadcast i need to set the entertainment service as ready for new connections. There is a key in hue api that reflect the service status and can be true or false.
If i'm not wrong the timeout is usefull there because once the entertainment app stop the broadcast i need to set the entertainment service as ready for new connections. There is a key in hue api that reflect the service status and can be true or false.
Without being too read up on the Hue API, I understand the reasoning, however, entertainmentService() never really stops running, and is constantly listening for traffic, and is therefor constantly throwing out the quiet exception.
As far as I can see, we hit a timeout at:
data = serverSocket.recvfrom(106)[0]
which triggers an exception, dropping us down to:
if syncing:
which we've already got set as false, then the function is run all over again.
Do you perhaps mean:
for group in groups.keys():
We're not able to reach this unless we've begun running the rest of the function and throw an exception. As far as I can see in the code, we should only really hit a timeout exception during data = serverSocket...
which shouldn't be necessary, but I might be wrong!
Just some thoughts!
@JohnBFrm @mariusmotea any news for this issue? Would love to use hue entertainmain again :D
I debug this issue and is not good. The problem seams to be in the C compiled entertainment service that was not made by me. I will try to recompile it, maybe it will start working.
. Performing the SSL/TLS handshake... hello verification requested
. Waiting for a remote connection ... ok
. Performing the SSL/TLS handshake... ok
[ Protocol is DTLSv1.2 ]
[ Ciphersuite is TLS-PSK-WITH-AES-128-GCM-SHA256 ]
[ Record expansion is 37 ]
[ Maximum fragment length is 16384 ]
. Verifying peer X.509 certificate... ok
2019-07-30 10:31:20,318 - root - INFO - Entertainment Service was syncing and has timed out, stopping server and clearing state
mbedtls_ssl_read returned -0x45
interrupted by SIGTERM (not in net_accept())
. Cleaning up... done.
i made a mistake, seams the issue is that now the port is added in lights_address. I will fix it.
Fixed with commit https://github.com/diyhue/diyHue/commit/4af4993c28c83fa5d6ca3e5caba8e16c0cd5351c
For all other users a new light search may be needed in order to add the port in light address.
I don´t know exactly why hue entertainment doesnt work (i can setup an entertainment area, but lights don´t recognize color changes), but i get following error when running in debug mode: Is it possible this causes the problem?
Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner self.run() File "/usr/lib/python3.7/threading.py", line 865, in run self._target(*self._args, **self._kwargs) File "/opt/hue-emulator/functions/ssdp.py", line 28, in ssdpSearch data = data.decode('utf-8') UnicodeDecodeError: 'utf-8' codec can't decode byte 0xdb in position 377: invali d continuation byte