"not reachable" messages in Debug Window

[larrybell]

I seem to get a lot of messages in the Debug window that says 8/27/2018, 6:27:15 PMnode: Shop Fan msg : string[13] "not reachable" I notice the device seems to go back and forth between connected and not reachable. Not sure what is causing this maybe you have some ideas.

Is there a way to send these messages somewhere besides the debug window?

Thank you, Larry

[mental-os]

Hey Larry, you can see them in Node's console too. Most def. you will see "TCP Timeout" and that means, most of the time, that your pooling events are triggered way too fast for your connection to handle them. Try one of those or all of them:

• [ ] increase pooling timeout;

• [ ] increase TCP timeout in Node's settings.js;

• [ ] decrease network interference;

• [ ] reset the switch (by reconnecting to router or by erasing it's settings to default).

[RKF-FKR]

Sadly I have this problem too. It's just randomly appeared after operating reliably for 6 months. I've not upgraded anything - it literally just started. Now the device can no longer be controlled using Node-Red I have 4 other HS100 that do no show any problem. I tried the suggestions above without success, including resetting the HS100 I tried a complete reinstall and even trying NR on different other Pi's (Pi 2 and Pi 3) the problem remains exactly as described by @larrybell The HS100 operates flawlessly through the KASA app. Mystifying...

[mental-os]

Something must have changed recently on your network @RKF-FKR given the successful history of past 6 months. However I can confirm this happens on the original source of the fork and also with the vanilla API. I will keep this open until we figure out why it's occuring.

Later: For what I can tell right now, distance of devices to the router and the quantity of devices on the same wi-fi is a factor.

[RKF-FKR]

Thanks @mental05 for your quick reply. Thinking hard about any network changes I can only say that I identified the HS 100 with a different name in my router device menu. (I renamed it from "HS100" to "bedroom lamp") I reset this all as part of my trouble shooting. I also removed the unit from the wall for an hour while painting.
I tested the offending HS100 alongside the router to see if I could achieve a greater success. But it didn't resolve the issue. I'm not that wifi crazy in number - I have 17 wifi devices connected to a Fritz 7390. So I'll try a brand now out-of-box HS100 in the identical position for a week and see if the same thing happens. All the best.

[mobamoba]

I'm having this issue as well and I think the source is that the Poll rate isn't being respected and it's flooding the plug with info requests. When I attach a message payload to the node, I get nonstop messages, like hundreds in a few seconds, despite my poll being set to 10000. I think this is the reason for the "not reachable" because the nonstop polling flood the device and makes it unable to respond to requests.

Is there a way to make the node actually respect the poll rate as I think this would take care of the problem? Thanks.

[gtalusan]

I'm seeing the same problem. Re-starting the node-red instance usually fixes it.

When the repeated TCP Timeout occurs, I can ping the affected HS100 from the node-red instance and can talk to it via tplink-smarthome directly.

[JsBergbau]

I have the same problems. Device changes within a few seconds between

Pinging the device from Node-Red Server in SSH --> no problems. Using ./tplink_smartplug.py -t 192.168.178.128 -c info returned always the info Script from there https://github.com/softScheck/tplink-smartplug

Device is in line of sight 3 meters from Wifi AP away.

Hardware revision is v2.0

I've already reset the device to factory defaults and reconfigured. Still problems exists.

[mobamoba]

Are you by chance using node red in docker? Because when I ran this plugin on Docker for Windows, I constantly got the not reachable error. When I ran it in regular Ubuntu VM, it ran without error.

[JsBergbau]

No, no VM or docker. Its running on a Rasbperry PI 3. Strange thing is, I've added another HS110. There no unreachable messages occur. I have 6 devices. I've just addes the others. 3 of them work correct and update their energy settings. The other 3 often go to state "unreachable" when next event poll interval (1 seconds) occurs. But even if you set this to a higher value, device still goes to "Not reachable"

[mobamoba]

I don't know if this will help, but at some point I reset them and assigned then static IPs in my router. If you haven't done that already, maybe it will help?

[JsBergbau]

The IP is quasi static. Controlling them with Kasa App, OpenHab Binding and the Python Script works and worked always flawlessly. So I'm very confused now why there are such problems with Node-RED.

[JsBergbau]

OK. I've found out. Problem was because time was not synced to the devices. However this should not lead to error unreachable. To find out I've modified smart-plug.js line 49 if (node.isClientConnected()) node.deviceInstance.getInfo().catch(() => {return node.handleConnectionError()}); to if (node.isClientConnected()) node.deviceInstance.getInfo().catch();

That leads to following log entries:

(node:23513) UnhandledPromiseRejectionWarning: ResponseError: err_code response: {"emeter":{"get_realtime":{"current":0.014796,"voltage":237.913969,"power":0,"total":0,"err_code":0}},"schedule":{"get_next_action":{"err_code":-11,"err_msg":"time not sync"}},"system":{"get_sysinfo":{"err_code":0,"sw_ver":"1.1.4 Build 170417 Rel.145118","hw_ver":"1.0","type":"IOT.SMARTPLUGSWITCH","model":"HS110(EU)","mac":"XXXX","deviceId":"XXX","hwId":"XXXX","fwId":"XXX","oemId":"XXXX","alias":"Universal","dev_name":"Wi-Fi Smart Plug With Energy Monitoring","icon_hash":"","relay_state":0,"on_time":0,"active_mode":"none","feature":"TIM:ENE","updating":0,"rssi":-59,"led_off":0,"latitude":0,"longitude":0}},"cnCloud":{"get_info":{"username":"","server":"devs.tplinkcloud.com","binded":0,"cld_connection":0,"illegalType":-1,"stopConnect":-1,"tcspStatus":-1,"fwDlPage":"","tcspInfo":"","fwNotifyType":0,"err_code":0}}} command: {"emeter":{"get_realtime":{}},"schedule":{"get_next_action":{}},"system":{"get_sysinfo":{}},"cnCloud":{"get_info":{}}}
    at processResponse (/home/openhabian/.node-red/node_modules/tplink-smarthome-api/lib/device/index.js:86:11)
    at Plug.sendCommand (/home/openhabian/.node-red/node_modules/tplink-smarthome-api/lib/device/index.js:370:21)
    at async Plug.getInfo (/home/openhabian/.node-red/node_modules/tplink-smarthome-api/lib/plug/index.js:353:14)
(node:23513) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 13)

Subscribed was only "getMeterEvents" So why does it try to get sheduled events? Why does any error code lead to "crash" of the whole node?

If you try to subscribe "getMeterEvents" to an HS100 Smartplug which doesn't have this e-meter device also gets unreachable. This also shouldn't happen, because you can still switch in ON or OFF. But as long as device is in unreachable state, you can't switch it on or off.

Via settime.sh <IP> from https://github.com/JsBergbau/tplink-smartplug you can set the time and then this error message is gone.