Hello, every once in a while, my light switches won't respond to any commands, and when I check the log, after every command sent is an error that reads "Calling SetIOMulti in plugin Wemo:Unable to connect to the remote server". Cycling the plugin restores functionality, while also producing one more error: Calling SetIOMulti in plugin Wemo:The given key was not present in the dictionary. Is there something on my end causing this?
Announcement
Collapse
No announcement yet.
Unable to connect to the remote server
Collapse
X
-
Originally posted by bla8291 View PostHello, every once in a while, my light switches won't respond to any commands, and when I check the log, after every command sent is an error that reads "Calling SetIOMulti in plugin Wemo:Unable to connect to the remote server". Cycling the plugin restores functionality, while also producing one more error: Calling SetIOMulti in plugin Wemo:The given key was not present in the dictionary. Is there something on my end causing this?
How often does this happen?
Does it happen to the same switch or multiple switches?
When this is happening are you able to use the Wemo phone app and still see the devices?
-
The frequency varies. It can happen about once or twice a day, or just once a week.
When I get the error, some or all of the switches are unresponsive. It's not the same switch every time. For example - last night I tried turning off all the lights using a shortcut on my phone, and only the living room lights turned off, but nothing in my bedroom did.
I never tried the Wemo app while this was happening but I was running another local Wemo controller side by side with your plugin, and that controller still worked. Now I only use your plugin. I will try the Wemo app next time it happens.
Comment
-
Another question, when this happens and the devices do not respond to commands from the plugin, if you manually change the state of the switch, does Homeseer still update the device state in Homeseer?
Ok, thanks for the great information. Give me a bit to modify some code to help us get to the bottom of this.
I plan to attack this in the following way:
1: More meaningful error logging that let's us know how it's failing
2: When the action or connectivity fails, try to verify if the IP is even reachable by pinging the IP and reporting the result.
3: For devices that routinely fail to communicate, read the signal strength of the device and record the average strength and report a warning log when/if it starts to dip below that.
4: Add some more error logic to ensure that any failures to communicate do not cause cascading problem to impact future polls.
I may also look into creating a homeseer device to indicate signal strength or reachability and/or last time a successful communication took place.
The way the plugin works right now is to issue an SSDP discovery to the network every 10 minutes, and for each Wemo device it discovers to send a message to the device telling it to notify the plugin for any changes in state. Then every 6 minutes it sends another message to that device to renew that message subscription.
Comment
-
I've realized that a big part of this problem was due to the wifi channel set on my router. I had it set to automatic, and it chose a channel that was conflicting with other networks in my building and causing the devices to disconnect. I changed the channel and things have improved significantly. They even respond quicker than before, whereas before, they would sometimes lag or the command would timeout.
Comment
-
The design is like this...
Send a message to the switch subscribing to any change in status and set the timeout value of this subscription to 10 minutes.
Every 6 minutes renew the previous subscription.
As the switch changes state, it sends the notification to the plugin.
If this is insufficient due to spotty coverage, perhaps I need to rework the algorithm a bit. I appreciate any feedback you can provide so that I may make improvements to the plugin.
Comment
-
I was using an Android app called AutomationManager to control them locally before using Homeseer, and whenever a device went offline, the app would detect that and show it as such. So I suppose that it would resend this subscription once it was able to contact the device again.
With your plugin, an offline device isn't detected until a command is sent, which then causes the "unable to connect to the remote server" error in the log. After coming back online, even though the device control still works, rules that monitor the state of the device don't work since it's out of date. I have the plugin set to restart automatically once a day to fix this.
I think it would be better to actively monitor the connection status of the devices, pinging each device maybe every 30 seconds or every minute. Use the root of every device to display the connection status or create a new child device to display it. If a ping request fails, send a few more requests immediately to confirm, then display the device as offline if those additional requests fail as well. When the device comes back online, resend the subscription message. I think this would eliminate the need for the user to restart the plugin every time a device goes offline.
Comment
-
Originally posted by bla8291 View PostI was using an Android app called AutomationManager to control them locally before using Homeseer, and whenever a device went offline, the app would detect that and show it as such. So I suppose that it would resend this subscription once it was able to contact the device again.
With your plugin, an offline device isn't detected until a command is sent, which then causes the "unable to connect to the remote server" error in the log. After coming back online, even though the device control still works, rules that monitor the state of the device don't work since it's out of date. I have the plugin set to restart automatically once a day to fix this.
I think it would be better to actively monitor the connection status of the devices, pinging each device maybe every 30 seconds or every minute. Use the root of every device to display the connection status or create a new child device to display it. If a ping request fails, send a few more requests immediately to confirm, then display the device as offline if those additional requests fail as well. When the device comes back online, resend the subscription message. I think this would eliminate the need for the user to restart the plugin every time a device goes offline.
Comment
-
I am also receiving the "Calling SetIOMulti in plugin Wemo:Unable to connect to the remote server" error using plugin v1.1.40718.33645, and am unable to operate the Wemo devices from Homeseer. I must resort to using the Wemo App to control the devices. Restarting the Wemo plugin resolves the issue for a while. This seems to happen several times per week and affects all three of my Wemo switches in various areas of my home well-covered by WiFi signal strength.
At the time of this writing I noticed that v1.2019.0112.1676 is now available. I'll upgrade and give it a try.
Comment
-
I've been running the update since its release, and I can't say I've seen any errors. The problem that remains is that after an undetermined amount of time of the switches being online, commands sent from HomeSeer have no effect. The only reason it took me so long to notice is that I had a script set to run in parallel with my lighting events to perform the same action in case the HomeSeer commands fail. I tried to turn on a switch directly from the HS homepage and it didn't work. The strange thing is if the switch is turned on locally, the status updates in HomeSeer.
Comment
-
The plugin works using several communication methods. When the plugin starts up and every so often it sends out a discovery message to find all switches/plugs. It then goes to all of them and sees if they're already in HomeSeer, if they're not it adds them. It then sends a subscribe request to the switch/plug to ask it to inform HomeSeer if the switch/plug changes it's status.
This would explain why you're still receiving status updates from the plugs. At this point I'm not 100% sure what would be causing the plugs to not be responding to the plugin.
Is it all the plugs at the same time or do they just randomly 1-by-1 stop working?
Do they start working again at anypoint other than when you restart the plugin?
Is it a specific model/type of switch/plug that stops or all of them?
How long after the plugin is running does it take for them to stop working? (hours? days? weeks?)
Do the plugs/switches have good wireless signal? Do you live in area with congested wireless coverage?
Comment
-
I might be able to provide helpful answers, as this bug also still affects my setup. I am using plugin v1.2019.112.1676 on HS3 Pro. See inline responses:
Originally posted by kingfetty View PostAt this point I'm not 100% sure what would be causing the plugs to not be responding to the plugin.
Is it all the plugs at the same time or do they just randomly 1-by-1 stop working?
Do they start working again at anypoint other than when you restart the plugin?
Is it a specific model/type of switch/plug that stops or all of them?Two of: WeMo_WW_2.00.11143.PVT-OWRT-SNSV2One of: WeMo_WW_2.00.11057.PVT-OWRT-SNS
How long after the plugin is running does it take for them to stop working? (hours? days? weeks?)
Do the plugs/switches have good wireless signal? Do you live in area with congested wireless coverage?
Comment
Comment