Throwing new TypeError on Windows 10 Docker Desktop
RobertD502 opened this issue · comments
I seem to be experiencing a problem, which was not present before. I had previously set up the container to run on port 4500 for a LG C8. For some reason, I was never able to use the tvon URL to turn on the TV, however, I was able to call the tvoff url to both turn on and turn off the TV. At the time everything worked just fine. I then went ahead and ran a second instance of the container but this time on a different port (5000) in order to be able to control a second C8. This is when everything went downhill.
I initially ran the tvoff url for the second TV (with different port from the first tv container), which prompted me with the screen to accept the connection. Once accepted the TV turned off. When I ran the tvoff url again, instead of turning the TV on as it did for the first container instance I received the TypeError seen below. It is as this point that I was no longer able to call the tvoff URL for the first container with it also throwing this error. I went ahead and deleted the second container for the second TV, but docker would continue to throw this error when calling the tvoff url to turn on the first TV. From here on, I completely removed docker and any any associated files/images. When attempting to get a single container running I am always faced with this error. Any help would be appreciated as I had it working prior to attempting to run two instances on two different ports.
Edit: Just installed docker on another Windows PC and still receive the same error.
Use the following URLS:
http://container_ip:5000/tvon
http://container_ip:5000/tvoff
http://container_ip:5000/mute
http://container_ip:5000/unmute
TV Power Status Change Detected
Opening Callback URL for TV On
undefined
undefined
Request: tvoff
TV Power Status Change Detected
Opening Callback URL for TV Off
undefined
undefined
Request: tvoff
timers.js:348
throw new TypeError('"callback" argument must be a function');
^
TypeError: "callback" argument must be a function
at exports.setTimeout (timers.js:348:11)
at LGTV. (/app/LGTVbridge.js:90:9)
at emitOne (events.js:96:13)
at LGTV.emit (events.js:191:7)
at WebSocketClient. (/app/node_modules/lgtv2/index.js:82:18)
at emitOne (events.js:96:13)
at WebSocketClient.emit (events.js:191:7)
at ClientRequest.handleRequestError (/app/node_modules/websocket/lib/WebSocketClient.js:227:14)
at emitOne (events.js:96:13)
at ClientRequest.emit (events.js:191:7)
Could I see your Docker Run command please? If you paste it here I'd like to see the whole thing including the parameters/formatting used, but make sure you change the token value in the callback urls to xxx (please keep the rest of the URL).
Actually... don't worry - I think I've seen one of the issues. There are a couple of rogue returns being called if it detects an error while calling the callback URL. The container quits instead of carrying on. I will push out a fix for that later on today if I get chance.
I've also reproduced the callback failure problem which only seems to happen occasionally. Not sure why - that needs more investigation and debugging so I'll get back to you on that.
As a side note: when you call tvon, the first thing the function does is attempt a wake-on-LAN to the TV MAC address you provided. You should do a bit of magic packet troubleshooting and make sure that the Docker host is able to send a magic packet to the TV's MAC address and wake it up. SolarWinds have a free and very simple Wake-On-LAN tool you can use on Windows to test, but there are literally hundreds out there to choose from. Also, the container must have its network settings configured in host mode, or the magic packets don't get through.
New version pushed out. Can you update (including the webCoRE piston if you're using that) and let me know how you get on?
Still experiencing the issue. For starters, since I am running this on windows and --net=host isn't supported, I map the port on the host to the container. Therefore, my docker command is:
docker run -p 4000:4000 -e TV_MAC="XX:XX:XX:XX:XX:XX" -e TV_IP="192.168.1.152" -e SERVICE_PORT=4000 -e CALLBACK_URL_ON="xxx?TurnIt=on" -e CALLBACK_URL_OFF="xxx?TurnIt=off" sockhamster/lgtv-bridge
The webcore piston is working as intended and correctly identifies the current power state of the TV. The initial run asks me for permission on the TV after I send it the off command and the TV turns off once I accept. The power state updates on the virtual switch at this point. I then send it the on command, but nothing happens. I can see that the turnon command is activated in the docker container however, nothing happens. I then send the turnoff command which eventually returns "TV refused connection, trying again in 2 seconds..."
I have tested it with other WOL software and sending magic packets on port 9 turns the tv both On and Off, so, I am a bit stumped as to why the WOL commands from this aren't able to.
I suspect this has to do with the fact that the WIFI card is not staying on as it should when the TV is powered off. On a side note, the LG Remote iOS App is supposed to discover the TV when it is powered off so that the app can be used to turn on the TV from there, but I noticed that the TV is not discoverable as soon as it is turned off. However, I did notice at one point yesterday that the TV was discoverable on the app when it was turned off, but I'm assuming this happened because the TV was on for several hours prior to being turned off and as a result the WIFI card remained on as it should.
I have a C9 at my residence that I will test this on as well and will report back. This seems to be a commonly reported problem with LG TV sets when attempting to use the mobile App to turn on TVs with the Mobile TV setting turned on.
Quick Update: As suspected, it seems that the TV had to be on for several hours in order for the WIFI card to remain on once the TV is powered off. Interesting enough, WOL packets don't work when called with the tvon url. I have gone around this by updating the webcore piston to call the tvoff url for both turning on the TV and turning it off as the tvoff function is able to do both while still reporting the correct power state on the virtual switch. Whether the WIFI remains on remains to be seen. I will report back after seeing if pinging the device for the power state forces the WIFI card to remain on.
WOL packets only work from containers when the container's network configuration is in host mode - the magic packets can't traverse the NAT used by the other modes. WOL shouldn't work to turn off the TV because this is done by using a direct connection to the TV's API and requesting it to turn itself off. Also, WOL is only really reliable when turning on ethernet-wired devices. If using WiFi, it's likely that the magic packet would be dropped or the TV not respond (its adapter might not be listening).
I've had a think about this and I don't think there's any way to get WOL working properly using a Windows Docker host. But, are you using SmartThings and my WebCoRE piston? If so, it should be a very easy tweak to the piston to get it to do the WOL instead. Change line 55 (which makes a GET request to the container to turn on the TV) to a "Wake LAN Device" command instead. Your virtual switch in SmartThings will then use the piston's WOL command to turn on the TV instead of asking the container to do it.