- 24.2% of a total CPU time of 24.9% of the uptime for the applications. ==> 6% cpu
- 37.5% of a total CPU time of 9.8% of the uptime for the devices. ==> 3.7% cpu
Thus is just my interpretation, but that doesn't seem too bad to me. Probably wrong.
Just throwing something out there, but could you be getting the overload only when, for example, the WeMo devices are doing their thing every refresh/poll in the WeMo connect app?
If you can, could you disable the WeMo Connect app and see if things settle down. If you do disable it, I would check in the logs to make sure it is actually disabled. Someone has said on the forum that they didn't get disable to work on their apps.
Good luck.
1 Like
I'll give it a shot, thanks.
Can anyone else with an Insight confirm that the power reporting either does or does not regularly report values (kWH) for you?
Mine only report power use when I click the "On" button. At the moment I have a NR flow that presses the "On" button for my Insight switches every 5 minutes - but that sees like a poor solution.
I actually just noticed this myself. I went to use the power reading for some automation logic and realized it didn't get new data unless I hit "subscribe" or turned the power on/off. My events confirm that updates are sporadic, and likely due to other automation turning the power on/off.
@jason0x43 any thoughts on what's going on here?
If you're getting updates when turning the power off and on, then Hubitat has a working subscription to the device. You can double check that by turning the device off and on outside of Hubitat and verifying that the status updates in Hubitat.
Assuming the subscription is good but power reporting is still sporadic, you could check the debug log for the Connect app to see if it looks like power readings are being received by the app and just not reflected in the devices. If that's the case, it should be easy enough to fix. If no power events are ever being received by the Connect app...I'm not sure.
@jason0x43 so it appears that the updates I'm seeing when changing to on/off are hard coded somewhere. When I turn off the power goes to 0, when I turn on it goes to 1. The debug logs on the wemo connect app seem...incomplete I guess is the best word for it. I am noticing a bunch of warnings saying "Cannot invoke method hexStringToInt() on null object" pretty much any time I interact with the WeMo. Here's a sample of what comes out when I turn the switch on.
2021-02-21 10:00:39.614 am debugCreating energy event for 456295
dev:332021-02-21 10:00:39.605 am debugCreating power event for 1235
dev:332021-02-21 10:00:39.601 am debugCreating binary state event for 1
dev:332021-02-21 10:00:39.596 am debugEvent params: [1, 1613919637, 1, 35784, 633144,
1209600, 1, 1235, 456295, 513473714]
dev:332021-02-21 10:00:39.592 am debugparse: Notify: BinaryState =
1|1613919637|1|35784|633144|1209600|1|1235|456295|513473714
dev:332021-02-21 10:00:39.562 am debugparse: received message
dev:332021-02-21 10:00:35.532 am debugCreating energy event for 456295
dev:332021-02-21 10:00:35.523 am debugCreating power event for 535
dev:332021-02-21 10:00:35.518 am debugCreating binary state event for 8
dev:332021-02-21 10:00:35.514 am debugEvent params: [8, 1613919633, 387, 35783, 633143,
1209600, 1, 535, 456295, 513473714]
dev:332021-02-21 10:00:35.510 am debugparse: Notify: BinaryState =
8|1613919633|387|35783|633143|1209600|1|535|456295|513473714
dev:332021-02-21 10:00:35.481 am debugparse: received message
dev:332021-02-21 10:00:33.950 am warnCannot invoke method hexStringToInt() on null object
dev:332021-02-21 10:00:33.906 am debugCreating energy event for 456295
dev:332021-02-21 10:00:33.896 am debugCreating power event for 0
dev:332021-02-21 10:00:33.891 am debugCreating binary state event for 8
dev:332021-02-21 10:00:33.887 am debugEvent params: [8, 1613919627, 387, 35783, 633143,
1209600, 1, 0, 456295, 513473714]
dev:332021-02-21 10:00:33.883 am debugparse: Got SetBinaryStateResponse:
8|1613919627|387|35783|633143|1209600|1|0|456295|513473714
dev:332021-02-21 10:00:33.859 am debugparse: received message
dev:332021-02-21 10:00:33.770 am infoTurning onReceiving one or more events when the state changes is normal enough. A binary state value of 8 means "standby" (theoretically), so that's a bit odd as an "on" value, but still valid.
Ugh, the hexStringToInt bit is annoying. I posted an update for the Connect App (just the app) that handles what appears to be the last unguarded use of hexStringToInt, so hopefully that will take care of that issue. That particular part of the code is what updates a child device's port value, so an error there could have been preventing port updates. Maybe.
@jason0x43 Hey I just caught up with this and updated all of the drivers and app, When I run the app, I see a lot of dupes or what I think are dupes. Do I need to add them or is it unnecessary? Retaining wall is the one where it looks like its finding a different MAC address but the IP/Port are the same. I still have a couple that are not found but I don't think there is a fix for that. Happy to send you one of those as well since I have an extra.
Anyone notice a general slowdown in the wemo’s reporting since the update? (same slippery slope as smarthings)
I used to tie one wemo switch to a separate hue light and it was always instantaneous.
Now it takes 5-8 mins.
Really hope this can be resolved. Don’t think it’s the app- but the hub
Given that Wemo is only community supported, i.e. NOT on the compatibility list (List of Compatible Devices - Hubitat Documentation) your assertion that the hub may be at fault is somewhat irrelevant. Suggest you contact the app developer and see if they have suggestions for you.
The duplicate devices are happening because, unbeknownst to me originally, WeMo devices have two MAC addresses. One is (usually) received in SSDP messages, and one is listed in the devices UPnP setup data. I had originally been using the SSDP one, but given that users were having issues with SSDP in newer devices, I switched over to using the one from the UPnP setup data. Devices are identified by MAC address, so that changed the device IDs. So, the newer device entries are the better option to use in the long run.
Hi @jason0x43
I just joined hubitat family and using your app to add my wemo devices. Scrolling through 311 posts here and I am still not sure if the issue correct status not updated by using physical button on the switch has been fixed? I linked 2 devices using a wemo switch but it is working very intermittently. Would you please shine me some light? Thank you
Yeah, WeMo was most of my entire logs, I back it off to 15 minutes, can it be set even longer?
Mine works fine, still probably using a old driver though... ... Yep, Last updated: 2019-06-09, 23:21:45-0400
FNG here. Just got my HE on Friday and I'm going through the steep learning curve. I have a number of ZigBee devices working. A couple of Iris wall plugs, a GE Zigbee wall switch and now the challenge is WEMO. I have about 7 wall switches plus a couple of mini's.
I downloaded and installed both WEMO connect and all the WEMO drivers. However, like many newby's I can't get HE to find the WEMO devices. They are all working fine in my wemo app. My wifi is on a separate subnet XXX.XXX.1.0/24 while my home subnet is XXX.XXX.10.0/24. I can ping all my WEMO devices from my home subnet. I briefly looked through the Wemo Connect code and did not see any variable that points to the WIFI subnet.
I could be totally off base with the subnet issue though.
Any assistance would be very welcome at this point.
I have had all kinds of Home Automation systems, Smartthings, Home Assistant, and others. HE is by far the best I've seen to date.
Glenn...
Has anyone been able to get their Wemo Dimmer Switch recognized by Hubitat?
I have no problems getting a Wemo Light Switch recognized by @jason0x43 switch driver but cannot get the dimmer working with the dimmer driver.
Any suggestions on resolution? Anyone else have the same issue?
Sorry to drop in on your thread - I saw the:
BlockquoteThey are all working fine in my wemo app. My wifi is on a separate subnet XXX.XXX.1.0/24 while my home subnet is XXX.XXX.10.0/24. I can ping all my WEMO devices from my home subnet.
Since /24 mask the two private nets can't be traversed unless a multihome device or NATting router is between them (and thats always been sketchy!) Do you have the ability to try a test bulb on the same subnet? - maybe consider changing your subnet to span both nets?
@jason0x43 any thoughts on getting the dimmer recognized by HE?
Unfortunately I don't think I can help out much, at least not any time soon. I don't have any WeMo Dimmers (I'm down to just one remaining WeMo switch), which makes development and debugging difficult. However, a bigger issue is that I don't have any free time to work on it at the moment. 
PRs are always welcome, if anyone else wants to look into it.
