Home app changes freeze homebridge and/or homebridge-wemo plugin
Closed this issue · 22 comments
What issue do you have? Please be as thorough and explicit as possible.
After initial discovery of wemos and display in the Homekit Home app, any subsequent change to a device, such as placing it in a specific room name, causes all logging (and apparently activity) in homebridge and/or the plugin to freeze. Simultaneousley, all bridge accessories disappear from the Home app. Restarting homebridge successfully rediscovers all wemos and the bridge with its accessories reappear in Homekit.
Details of your setup.
- Do you use (1) Homebridge UI-X (2) Homebridge CLI or (3) HOOBS?
I'm running a freshly installed Homebridge UI-X on MacOS 10.14.6 (Mojave). There is ONLY the homebridge-wemo plugin installed.
- Which version of this plugin (homebridge-wemo) do you have? Has the issue started since upgrading from a previous version?
homebridge-config-ui-x v4.41.5
homebridge-wemo v4.5.1
node -v -> v16.13.1
npm -v -> 8.1.2
My previous system, running MUCH older versions of both homebridge and homebridge-wemo ran for 3 or 4 years without any issues until yesterday for the same wemos. All wemo devices are exactly the same as before moving to the newer version and all work perfectly with the Belkin app. These are: 1 Wemo Link with 5 bulbs + 2 Wemo Smart Plugs.
No iOS versions have changed.
- Which Wemo devices do you have that are causing issues? Please include product models if applicable.
The issue appears to be coming from the Home app / Homekit... but "homebridge-wemo" is the ONLY plugin.
Please paste any relevant logs below.
I have turned on all logging I can find, including running "homebridge -D" in a shell. I can find no apparently relevant messages, since whatever Home app action (particularly setting up rooms) causes the log activity to stop and all bridge hub wemos to disappear.
Since I can find no good info in the log, I randomly change some settings for the plugin, such as increasing timeouts and and temporarily disabling UPnP. The Mac is on wired ethernet, so I forced binding to "en0". Nothing changed with any of these different settings. One thing I find in these settings that I do not understand is "UPNP Callback IP/Port" of 192.168.1.13:2021. There is no such IP address on my network, and the field is read-only, so I can't change it.
It's a good, solid, and fast network.
For what it's worth, below is an example of what comes out when I restart homebridge (in the UI) after losing all entries in the Home app. Logging is turned on for the plugin.
[0;37m[12/27/2021, 5:18:48 PM] �[0m�[0;36m[Homebridge UI]�[0m Changes to config.json saved.
�[0;37m[12/27/2021, 5:18:48 PM] �[0m�[0;36m[Homebridge UI]�[0m [homebridge-wemo] Terminating child process...
�[0;37m[12/27/2021, 5:18:48 PM] �[0m�[0;36m[Homebridge UI]�[0m [homebridge-wemo] Child process ended
�[0;37m[12/27/2021, 5:18:51 PM] �[0m�[0;36m[Homebridge UI]�[0m Homebridge restart request received
�[0;37m[12/27/2021, 5:18:51 PM] �[0m�[0;36m[Homebridge UI]�[0m UI / Bridge settings have not changed; only restarting Homebridge process
�[0;37m[12/27/2021, 5:18:51 PM] �[0m�[0;36m[Homebridge UI]�[0m Sending SIGTERM to Homebridge
�[37m[12/27/2021, 5:18:51 PM] �[39mGot SIGTERM, shutting down Homebridge...
�[37m[12/27/2021, 5:18:51 PM] �[39m�[36m[Wemo]�[39m SSDP client gracefully stopped.
�[37m[12/27/2021, 5:18:51 PM] �[39m�[36m[Wemo]�[39m Listener server gracefully closed.
�[37m[12/27/2021, 5:18:56 PM]�[0m �[36m[HB Supervisor]�[0m Homebridge Process Ended. Code: 143, Signal: null
�[37m[12/27/2021, 5:19:01 PM]�[0m �[36m[HB Supervisor]�[0m Restarting Homebridge...
�[37m[12/27/2021, 5:19:01 PM]�[0m �[36m[HB Supervisor]�[0m Starting Homebridge with extra flags: -I
�[37m[12/27/2021, 5:19:01 PM]�[0m �[36m[HB Supervisor]�[0m Started Homebridge v1.3.8 with PID: 7959
�[37m[12/27/2021, 5:19:01 PM] �[39mLoaded config.json with 0 accessories and 2 platforms.
�[37m[12/27/2021, 5:19:01 PM] �[39mLoaded 5 cached accessories from cachedAccessories.
�[37m[12/27/2021, 5:19:01 PM] �[39m---
�[37m[12/27/2021, 5:19:02 PM] �[39mLoaded plugin: homebridge-config-ui-x@4.41.5
�[37m[12/27/2021, 5:19:02 PM] �[39mRegistering platform 'homebridge-config-ui-x.config'
�[37m[12/27/2021, 5:19:02 PM] �[39m---
�[37m[12/27/2021, 5:19:02 PM] �[39mLoaded plugin: homebridge-wemo@4.5.1
�[37m[12/27/2021, 5:19:02 PM] �[39mRegistering platform 'homebridge-wemo.Wemo'
�[37m[12/27/2021, 5:19:02 PM] �[39m---
�[37m[12/27/2021, 5:19:02 PM] �[39mLoading 2 platforms...
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Config]�[39m Initializing config platform...
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Config]�[39m Running in Service Mode
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Wemo]�[39m Initializing Wemo platform...
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Wemo]�[39m Initialising plugin v4.5.1 | Node v16.13.1 | HB v1.3.8...
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Wemo]�[39m Plugin initialised. Setting up accessories....
Setup Payload:
X-HM://0023OA632ZDE8
Enter this code with your HomeKit app on your iOS device to pair with Homebridge:
�[30m�[47m �[49m�[39m
�[30m�[47m ┌────────────┐ �[49m�[39m
�[30m�[47m │ 123-45-678 │ �[49m�[39m
�[30m�[47m └────────────┘ �[49m�[39m
�[30m�[47m �[49m�[39m
�[37m[12/27/2021, 5:19:02 PM] �[39mHomebridge v1.3.8 (HAP v0.9.7) (Homebridge AE01) is running on port 51012.
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Wemo]�[39m Listener server port [62753].
�[37m[12/27/2021, 5:19:02 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] initialising with options {"logging":"debug","showAs":"outlet"}.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] initialised with s/n 221510K110065A and ip/port 192.168.1.192:49153
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] http has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] [urn:Belkin:service:basicevent:1] initial subscription for service.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] upnp has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] initialising with options {"logging":"debug","showAs":"outlet"}.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] initialised with s/n 221451K11003D2 and ip/port 192.168.1.191:49153
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] http has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] [urn:Belkin:service:basicevent:1] initial subscription for service.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] upnp has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] receiving update [BinaryState: 0].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] current state [off].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Gooseneck] initialising with options {"adaptiveLightingShift":0,"brightnessStep":1,"logging":"debug","transitionTime":0}.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Gooseneck] initialised with s/n 94103EF6BF427ED0 and ip/port 192.168.1.190:49153.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Light] initialising with options {"adaptiveLightingShift":0,"brightnessStep":1,"logging":"debug","transitionTime":0}.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Light] initialised with s/n 1640616639 and ip/port 192.168.1.190:49153.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Light] initialising with options {"adaptiveLightingShift":0,"brightnessStep":1,"logging":"debug","transitionTime":0}.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Light] initialised with s/n 1640616723 and ip/port 192.168.1.190:49153.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] initialised with s/n 231450B01001A4 and ip/port 192.168.1.190:49153
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] http has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] [urn:Belkin:service:basicevent:1] initial subscription for service.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] [urn:Belkin:service:bridge:1] initial subscription for service.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] upnp has been established.
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<BinaryState>0</BinaryState>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Switch] receiving update [BinaryState: 0].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<BinaryState>0</BinaryState>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] receiving update [BinaryState: 0].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] current state [off].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<BinaryState>0</BinaryState>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<TimeSyncRequest>0</TimeSyncRequest>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<StatusChange></StatusChange>
</e:property>
<e:property>
<SubDeviceFWUpdateStatus></SubDeviceFWUpdateStatus>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [WeMo Link] incoming notification:
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<TimeZoneNotification>005</TimeZoneNotification>
</e:property>
</e:propertyset>
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Living Room Switch] receiving update [BinaryState: 0].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Gooseneck] current state [off].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Gooseneck] current brightness [100%].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Light] current state [off].
�[37m[12/27/2021, 5:19:03 PM] �[39m�[36m[Wemo]�[39m [Bedroom Light] current brightness [100%].
�[37m[12/27/2021, 5:19:04 PM] �[39m�[36m[Wemo]�[39m [Living Room Light] current state [on].
�[37m[12/27/2021, 5:19:04 PM] �[39m�[36m[Wemo]�[39m [Living Room Light] current brightness [100%].
�[37m[12/27/2021, 5:19:04 PM] �[39m�[36m[Wemo]�[39m ✓ Setup complete. Interested in sponsoring this plugin? https://github.com/sponsors/bwp91
�[0;37m[12/27/2021, 5:34:09 PM] �[0m�[0;36m[Homebridge UI]�[0m [homebridge-wemo] Terminating child process...
�[0;37m[12/27/2021, 5:34:09 PM] �[0m�[0;36m[Homebridge UI]�[0m [homebridge-wemo] Child process ended
Small update: Maybe I am wrong to focus so much on the plugin behavior. I happened to notice the following in "system.log" just as my devices disappeared. It looks as though the entire service is crashing and restarting. Or, more accurately, simply crashing and not restarting, since to get the devices to reappear I have to manually do that.
Dec 28 07:38:09 HAL MobileDeviceUpdater[453]: tid:1a3f - Can't handle disconnect with invalid ecid
**Dec 28 07:39:56 HAL com.apple.xpc.launchd[1] (com.homebridge.server[36818]): Service exited with abnormal code: 2**
Dec 28 07:40:46 HAL iTunesHelper[452]: Entered:_AMMuxedDeviceDisconnected, mux-device:650
Hi @PudMuddle
Do you have any iOS devices on your 'homekit network' which are running older versions of iOS like 9, 10 or 11?
Hi @bwp91... Thanks for jumping onto my problem.
Yes, indeed I do! Just today I was considering the potential impact of that. In my house, I have three old iPhone 5 devices spread around that I have used for a long time to control HomeKit via Siri. These are running iOS 10.3.4. For the whole long time during which I ran old versions of Homebridge and the Wemo plugin, they have worked just fine. (A good use for old devices.)
Finally, last night I did manage to get a stable "home" to remain in place by installing the 1.3.9 beta of Homebridge. So, on all my more modern devices, everything is now running (almost) normally. These include my Mac (Mojave), an iPad, iPhone 7, and an iPhone 6S+, all running the latest iOS (15.2). I also have an iPhone 5S running iOS 12 that works fine now. There are two Apple TV 4's that act as HomeKit hubs, both up to date.
The old iPhone 5 devices are still a problem, though. I cannot remember if I had already turned these off when I finally managed to get things stable, but what I can say is that they now show Homebridge and all of its devices, although they show "No Response" on their respective Home app tiles. Interestingly, a native HomeKit LED light strip (bluetooth) works fine with these old iPhones. This does not go through Homebridge.
So, I am really starting to suspect that changes in Homekit since the time I originally set up the older version of Homebridge have resulted in it no longer working with these devices. That seems to be where you are leading with your question about old devices.... ?
The one thing I have not yet tried since getting it stable is to move a device to a different "room" in the Home app. This is what would cause all devices to disappear every time. I have left them in the default room.
What do you think?
Can you update to the beta version of the plugin (4.5.2-beta.0) and first look for any initial errors in the log as the plugin restarts, and let me know if this makes anything better?
Thanks again for your help... and apologies for the delay in replying. I'm in Europe, so there's a time difference between us.
I've upgraded to the 4.5.2-beta.0 plugin and simultaneously to the release version of Homebridge 1.3.9, since I noticed that it had become available. I do not see any errors in the log (attached) when restarting.
However, yesterday I made another change, since I had seen some timeout errors from the plugin trying to get the status from the accessories. More specifically, the actual message was saying that it could not determine the right port to use... It didn't specifically say that it couldn't find the device. (There are 3, each with a fixed IP configured via my router.) This only happened during a brief period, but I decided to add syntax I found in the documentation to help identify my three devices directly based on their IP address. I set the "Device detection" mode to "manual". Since then, I have not seen any timeouts. (Curiously, I don't see a syntax option to specify the port number. I did try adding it to the IP as xxx.xxx.xxx.xxx:49153, but the plugin did not like this syntax. I am able to know the right port number, because I wrote a bash script a long time ago that allows me to query and control the accessories directly from the command line.)
Also, another thing happened when I woke up this morning: The Home app on all my iOS devices showed "Loading accessories..." (or something to that effect). Restarting Homebridge did not help. But when I turned on my Apple TV, it asked me to "Finish setting up HomeKit". My other Apple TV was in the same state. When I performed this operation, everything went back to normal. At the moment, it's running fine.
Here are the changes I made to the plugin config. I'm also attaching the log.
{
"name": "Wemo",
"mode": "manual",
"debug": false,
"discoveryInterval": 15,
"wemoClient": {
"listen_interface": "en0",
"discover_opts": {
"interfaces": "en0",
"explicitSocketBind": false
}
},
"pollingInterval": 15,
"upnpInterval": 60,
"disableUPNP": false,
"wemoLinks": [
{
"label": "Wemo Link",
"serialNumber": "231450B01001A4",
"manualIP": "192.168.1.190"
}
],
"wemoOutlets": [
{
"label": "Living Room Outlet",
"serialNumber": "221451K11003D2",
"manualIP": "192.168.1.191"
},
{
"label": "Bedroom Outlet",
"serialNumber": "221510K110065A",
"manualIP": "192.168.1.192"
}
],
"platform": "Wemo"
},
and apologies for the delay in replying. I'm in Europe, so there's a time difference between us.
I am in the UK!
I did try adding it to the IP as xxx.xxx.xxx.xxx:49153, but the plugin did not like this syntax. I am able to know the right port number, because I wrote a bash script a long time ago that allows me to query and control the accessories by directly.)
The plugin automatically checks all the common ports that the devices use, since they can change over time without any warning! If you also want to specify the IP then you need to use the format http://xxx.xxx.xxx.xxx:49153/setup.xml
I also think changing to manual mode with all the specified IPs is a good idea. Config looks good.
At the moment, it's running fine.
So no more disappearing accessories? Since you made a number of changes, it's difficult to determine if the changes I made in the beta are the reason why it's working better. If you have the patience, could you downgrade back to the release version v4.5.1 to see if everything still works? Or if this leads to disappearing accessories again then I know the changes in the beta are necessary.
Thanks!
Oh... Haha... So there's only an hour's difference between us. I'm in France. For some reason, I thought you were in the US.
Thanks for the more specific syntax... The documentation is good, but it seems to be a little bit out of date. A couple of other options I initially included prompted the plugin to tell me that they were deprecated and that I could remove them.
Based on what you said about ports changing over time, I think I'll leave out that specification. I can really see that causing headaches in the case they did change.
Is there something specific you can tell me about changes made to HomeKit? I'm intrigued that you immediately asked me about old iOS version 9, 10, and 11. I do believe Apple as made some security changes to the platform in recent releases.
Keeping my fingers crossed... Thanks again!
Is there something specific you can tell me about changes made to HomeKit? I'm intrigued that you immediately asked me about old iOS version 9, 10, and 11. I do believe Apple as made some security changes to the platform in recent releases.
For the Wemo Bulbs I recently added the HomeKit Hue and Saturation characteristics to enable RGB colour changing. This is in addition to the existing ColorTemperature characteristic to allow for colour temperature changes.
The HomeKit specification says that lightbulbs should have either the ColorTemperature characteristic OR the Hue and Saturation characteristics, ie not both.
However in a lot of my plugins I add all the characteristics to enable better functionality, and it seems to work.
But I have started to wonder if adding all the characteristics is the reason why accessories are disappearing when there is a lower version of iOS on the homekit network. I have had a few issues over time regarding disappearing accessories for my different plugins, and in all cases the issue was a device with a lower iOS version on the network.
I still don't know the definite reason for this, but now with your issue I am trying to put two and two together, and am wondering if the reason for the disappearing accessories is in fact having all the characteristics on a lightbulb, and perhaps lower versions of iOS don't support this. Also when I say a 'lower' version of iOS, and if this is the reason, I don't know from which version of iOS it starts to work.
Does this make sense?!
So in the beta, I have removed the Hue and Saturation characteristics from the lightbulbs, so they just have the ColorTemperature characteristic.
If you downgrade back to v4.5.1, and it would be really interesting for me if you were able to, to see whether the accessories disappear again. This would indicate to me that this really is the issue, and has been all this time for other users!
That's all very interesting stuff. When I asked, I was actually thinking more about the actual bridge API/connection to HomeKit and not so much the plugin itself. But very interesting observations...
Just for info, the bulbs connected to my wemo link have no colors at all... only white. So, those characteristics would not work if they were applied, anyway. Could that be causing an issue? (I've also been wondering recently if other bulbs from other manufacturers would work with the wemo link...? Belkin does not sell these anymore.)
For just another bit of information, after having finished setting up the two Apple TVs this morning, I turned on one of the old iOS 10 devices to see if anything had changed. It hadn't. It shows all the devices, but they still say "No Response". The iOS 12 device works fine.
When I asked, I was actually thinking more about the actual bridge API/connection to HomeKit and not so much the plugin itself.
Ah I see. I'm not so familiar with the connection between homebridge and homekit - I'm much better with the plugin <-> homebridge side of things.
Just for info, the bulbs connected to my wemo link have no colors at all... only white. So, those characteristics would not work if they were applied, anyway
Yes you are correct, I assume in your case you only have the options of on/off and brightness?
I've also been wondering recently if other bulbs from other manufacturers would work with the wemo link...?
I think the only other bulbs that work are some Osram bulbs, you can see here:
https://www.belkin.com/us/support-article?articleNum=116172
old iOS 10 devices to see if anything had changed. It hadn't. It shows all the devices, but they still say "No Response"
Do they show as no response the whole time? Even if you force close the home app and reopen?
Thanks! I may have to get some... Or, to be honest, I may just go for bulbs and/or switches that work natively with HomeKit. There are lot more of those on the market now than there were at the time I bought my wemos.
About those bulbs... In more specific technical terms, I was thinking about the plugin sending "color commands" to the bulbs, as per your info about the options you've added, and about the fact that HomeKit may get upset with commands that don't apply a particular accessory. But again, I have to just think out loud in generic terms because I don't know the guts of HomeKit.
About the old iOS 10 device... Yes. They constantly display "No Response". That's strange to me, since it does clearly know they are there and also since in the beginning of my struggles over the past three days, those old devices worked during the time they remained displayed. Although I can't swear to it, it seems to me that the big change (including stability) came when I bumped the Homebridge version up to 1.3.9.
You could try reverting back to the version of homebridge you were on before to see if that fixes things?
Wemo plugin is difficult to maintain… the connection methods are strange and often the devices don’t behave very well, you could look into different brands that homebridge supports, I also maintain ewelink, meross and govee plugin and those brands have light bulbs. If you’re looking for local control i would probably recommend meross. Or even other brands which have plugins like magichome (i don’t actually know if they do bulbs), or tuya.
But of course, I can’t guarantee that any of the plugins will work with ios10. In this case of your issue, I’m uncertain whether it’s a plugin issue, a homebridge issue or a homekit issue. I normally recommend to just take these older devices off the homekit network, but I appreciate in some/most cases it seems like then a waste of a device, or just not feasible to remove it.
Hi @bwp91 ... Actually, that was one of the first things I did. I backed all the way down through the versions that are visible in the UI widget. I did the same with your plugin. However, the original versions of both of these that worked for so long for me are far too old to be included. At that time, there was no such thing as the web UI. I did everything by hand on the command line, including the config using vi.
I do understand what you mean about the wemos being difficult. I built a rather sophisticated shell script to control them, based on someone else's I found with most of the SOAP (via curl), so I've seen at least a little of what's involved and how they respond. Still, it works really well.
Hi Ben,
I've been following this up again, and I've gleaned some clues. There is clearly something that has been broken somewhere along the line towards the more recent versions of either Homebridge or the Wemo plugin (or maybe both). Here is why:
On the current versions (Homebridge 1.3.9 and homebridge-wemo v4.5.3), the situation is that all up-to-date iOS devices work properly, and none of my iOS 9, 10, or 12 version devices work. These devices properly display the bridge and its accessories, but they cannot communicate with them. Status update attempts just display "No Response". The log on the server show no request for this.
Quite by accident, I stumbled upon a free iOS app in the App Store that runs Homebridge, allowing you to turn an iOS device into a Homebridge server. It tried it, and - miracle! - it works perfectly on the iOS 12 device. This is very significant to me, since all the reading I have done about Apple's Homekit development indicate that real ground-level changes occurred in iOS 11, so these devices should be compatible. Looking at the logs generated by the iOS Homebridge server app, I see the following old module versions running:
- node v12.19.0
- homebridge v1.3.6
- homebridge-wemo@4.2.3
If you want to try it, it's called "Hub for Homebridge". Here's the link: https://apps.apple.com/us/app/hub-for-homekit/id1587542468
I really do not want to have to run an iOS app to use HomeKit. This has some real disadvantages... Although this app works great while it's running, if it gets put into the background to do something else, it stops working. Furthermore, I couldn't find an option to "Allow Background Update". I imagine this would be the same if the screen went to sleep, but I didn't think to try that. Still, it was a very useful test to prove that the iOS 12 and later version can work simultaneously.
I may be wrong, but I somehow suspect networking differences in the iOS versions in combination with Homebridge/Wemo as being at the heart of the matter. On the current Homebridge/Wemo versions, I have tried all manner of settings permutations to get the iOS 12 device to communicate... UPnP/HTTP polling, specific interface binding (en0), switching the service broadcaster between Bonjour/Ciao, etc. Nothing does it.
Since I have another Mac, I may try installing the old module versions I see in the "Hub for HomeKit" app to see if that works.
On another topic, more in line with my original reason for this post... I finally discovered why I originally had problems with devices sporadically disappearing a short time after initially showing up when pairing. The reason is that somewhere along the line of those hiccups, the HomeKit created a second "home" with the same name. When I deleted both of them, reset Homebridge, and started from scratch, they remained correctly in the configuration... although they won't work from the iOS 9, 10, or 12 devices.
You could try on your main homebridge instance to rollback say the plugin first to the earlier version, see if this works, if not then the plugin back to latest and rollback homebridge version to see if you can work out exactly what has made the different to your system
Actually, I have already tried almost every version available in the UI list (under "Install previous version") with no luck. However, good news! I just went a moment ago for the specific version 4.2.3 of the plugin, and it works. So, the problem does appear to be with the plugin and not Homebridge itself and also appears to have been introduced sometime between then and now.
In the log generated when restarting, there is only one line that refers to anything relevant... about a UPnP option in the config that is not recognized. This kind of suggests that changes may have been made that relate to this.
So, at least I have a solution... I can live with the "plugin out of date" message in the UI.
[1/7/2022, 9:46:44 AM] [Homebridge UI] Sending SIGTERM to Homebridge
[1/7/2022, 9:46:44 AM] Got SIGTERM, shutting down Homebridge...
[1/7/2022, 9:46:49 AM] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null
[1/7/2022, 9:46:54 AM] [HB Supervisor] Restarting Homebridge...
[1/7/2022, 9:46:54 AM] [HB Supervisor] Starting Homebridge with extra flags: -I -D
[1/7/2022, 9:46:54 AM] [HB Supervisor] Started Homebridge v1.3.9 with PID: 79132
[1/7/2022, 9:46:54 AM] Loaded config.json with 0 accessories and 2 platforms.
[1/7/2022, 9:46:54 AM] Loaded 5 cached accessories from cachedAccessories.
[1/7/2022, 9:46:54 AM] ---
[1/7/2022, 9:46:55 AM] Loaded plugin: homebridge-config-ui-x@4.41.5
[1/7/2022, 9:46:55 AM] Registering platform 'homebridge-config-ui-x.config'
[1/7/2022, 9:46:55 AM] ---
[1/7/2022, 9:46:55 AM] Loaded plugin: homebridge-wemo@4.2.3
[1/7/2022, 9:46:55 AM] Registering platform 'homebridge-wemo.Wemo'
[1/7/2022, 9:46:55 AM] ---
[1/7/2022, 9:46:55 AM] Loading 2 platforms...
[1/7/2022, 9:46:55 AM] [Config] Initializing config platform...
[1/7/2022, 9:46:55 AM] [Config] Running in Service Mode
[1/7/2022, 9:46:55 AM] [Wemo] Initializing Wemo platform...
[1/7/2022, 9:46:55 AM] [Wemo] Initialising plugin v4.2.3 | Node v16.13.1 | HB v1.3.9...
[1/7/2022, 9:46:55 AM] [Wemo] Config entry [upnpInterval] is unused and can be removed.
[1/7/2022, 9:46:55 AM] [Wemo] Plugin initialised. Setting up accessories....
[1/7/2022, 9:46:55 AM] Publishing bridge accessory (name: Homebridge, publishInfo: {
username: '0E:28:A5:97:75:2E',
port: 51012,
pincode: '--**',
category: 2,
bind: [ 'en0', [length]: 1 ],
mdns: undefined,
addIdentifyingMaterial: true,
advertiser: 'bonjour-hap'
}).
Setup Payload:
X-HM://002487VQJSLUM
BUT... in the few minutes since I posted the last comment, it stopped working again with the "No Response" status. If I turn off the Home option in iCloud settings on the phone in order to force the Home app to reload the configuration when I turn it back on, then the devices start to work again. No restart of Homebridge is required. Could that be a network timeout somewhere?
The changes between v4.2.3 and the current version are minimal, you can compare them out of interest here.
The only things that have really changed are:
- the addition of colour control to supported bulbs
- a custom upnp interval time (the older version is just complaining that you have this new config entry which didn't exist in this version)
- a fix for the wemo air purifier
- dependency and node version updates
So I really am stuck as to why it isn't working properly in the older iOS versions, but again, I have seen this issue in a few cases now, but actually in the other cases, just the existence of older iOS versions on the homekit network actually messed things up for all devices on the network including latest iOS versions.
It surely does seem that none of those things should be the culprit. Furthermore, I'm starting to shift my suspicions from the plugin to the Homebridge interface to HomeKit itself. When the issue occurs, HomeKit appears to simply remove the bridge from its configuration. The whole thing just disappears until restarting Homebridge, provoking it to re-annonce itself, I suppose. Any scenes I have set up referencing these devices also disappear and don't come back even after a restart. I have to re-create them. When the accessories do reappear after the restart, they are in the "No Response" status on iOS 12 and, in fact, never reappear at all on the iOS 9 iPhone 4S. BUT any genuine, HomeKit-certified accessory continues to work all along.
What I can indeed confirm is what you have said about old devices being a problem. When I got the whole thing stable the other day, I had not thought about having turned off the iOS 9 iPhone 4S. When I then turned it on again a couple of days later, it all went haywire again, after having run fine while it was off. I've found that the only way I can keep that phone on the network without it messing up HomeKit is to turn off the HomeKit option in the iCloud settings. The iOS 12 iPhone 5S is a little more tolerant, but it continues to display the "No Response" status for the bridge accessories after initially working for a couple of minutes if I've just re-paired. As I said above, any genuine, HomeKit-certified accessories continue to work.
Anyway, my solution is going to be to keep those old devices out of the HomeKit configuration by turning that option off in the iCloud settings.
This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed.