Hello
The idiom “Leave well enough alone.” is something I should have headed before upgrading to 2.5.0-1 from 2.4.0-1
After Upgrade to 2.5.0-1 Alexa says “…isn’t responding please check…” when asked to turn on or off a light.
Don’t see any warnings or errors in openhab.log
Using Hue Emulation and InsteonPLM.
Any ideas?
All I can suggest is to check addons.config in your userdata folder for invalid addons. That causes all addons to reload every minute. Also check addons.cfg file.
restdocs moved from misc to ui and yahooweather was removed and is not invalid.
Are you using openhabcloud? If so please post the output from var/lib/openhab2/config/org/openhab/openhabcloud.config
If not please post any error messages you have in the logs when trying to use Alexa.
Hi.
Not using openhabcloud.
Using Hue Emulation, InsteonPLM and reverse proxy via NGINX.
No messages generated in openhab.log when asking Alexa to turn on or off a light.
Physical operation of a switch results in these log entries:
openhab.log
2019-12-29 10:42:08.217 [DEBUG] [lm.internal.device.MessageDispatcher] - XX.XX.XX:GenericDimmer->LightOffDimmerHandler cmd1:0x13 group 1/1
2019-12-29 10:42:08.220 [INFO ] [onplm.internal.device.MessageHandler] - LightOffDimmerHandler: device XX.XX.XX was turned off REGULAR.
2019-12-29 10:42:08.225 [DEBUG] [eonplm.internal.device.DeviceFeature] - XX.XX.XX:GenericDimmer publishing: 0
2019-12-29 10:42:08.230 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: OnLevel
2019-12-29 10:42:08.233 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:08.238 [DEBUG] [eonplm.internal.device.DeviceFeature] - XX.XX.XX:GenericLastTime publishing: 2019-12-29T10:42:08
2019-12-29 10:42:10.212 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - got msg: IN:Cmd:0x50|fromAddress:XX.XX.XX|toAddress:xx.xx.xx|messageFlags:0x45=ALL_LINK_CLEANUP:1:1|command1:0x13|command2:0x01|
2019-12-29 10:42:10.215 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: FastOnOff
2019-12-29 10:42:10.219 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.222 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: RampRate
2019-12-29 10:42:10.226 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.229 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: LEDBrightness
2019-12-29 10:42:10.233 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.236 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: ManualChange
2019-12-29 10:42:10.240 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.242 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: ExtStatusGroup
2019-12-29 10:42:10.246 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.249 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: GenericDimmer
2019-12-29 10:42:10.253 [DEBUG] [lm.internal.device.MessageDispatcher] - message ignored as duplicate. Matches group: true matches filter: true
2019-12-29 10:42:10.256 [DEBUG] [eonplm.internal.device.InsteonDevice] - ----- applying message to feature: OnLevel
2019-12-29 10:42:10.259 [DEBUG] [lm.internal.device.MessageDispatcher] - msg is not for this feature
2019-12-29 10:42:10.264 [DEBUG] [eonplm.internal.device.DeviceFeature] - XX.XX.XX:GenericLastTime publishing: 2019-12-29T10:42:10
Logging Level
log:set DEBUG org.openhab.binding.hueemulationservice
log:set DEBUG org.openhab.binding.insteonplm
Try deleting one of the devices in the alexa app and try to rediscover it. If that works for one device then you know what do to for the rest. Maybe try removing it from OH and re adding as well.
If you’ve done that already then try uninstalling the bindings, stop OH, clean the cache, reboot and reinstall the binding.
After doing that my Insteon devices no longer show up in the Paper UI / ITEMS.
My insteon.items file is still in /etc/openhab2/items and contains all of my Insteon devices.
Has the formatting changed for the .items files?
edit: I did not delete the InsteonPLM binding.
What you have should work.
You can not delete an item from a file via PaperUI and you shouldn’t need to. It’s the Thing I would delete and reinstall on OH…Unless it’s created via files as well.
Stop and start OH a few time and see if everything comes back. If not go into the item file with editor and add // or something just to touch the file and save.
Only three items in Things
Local Moon
Local Sun
MQTT Broker
Do not believe I every had any Insteon referenced in Things
Touched the insteon.items file and rebooted. The Insteon devices are now back in the OH Items list.
Deleted a few Insteon devices from Alexa but was unable to find them again.
Is the Hue Emulation 2.5.0 not working with Alexa?
Did OH 2.4.0-1 use a different Hue Emulation binding?
Check what version you have via the console with bundle:list command. Also look to make sure there are no redundant bindings.
Try restarting OH. When I first upgraded, my text files were not read properly. A restart fixed things.
229 │ Active │ 80 │ 1.14.0 │ openHAB Insteon PLM Binding
245 │ Active │ 80 │ 2.5.0 │ openHAB Add-ons :: Bundles :: IO :: Hue Emulation Service
This is all that I find regarding Insteon and Hue Imulation
That version of Insteon is the latest but it’s a 1.x binding. I would remove the 1.x binding, stop OH, clean cache, restart and watch the logs. After OH is fully up and running make sure you have legacy mode turned on via PaperUI and reinstall Insteon.
I’m confused. So please be patient with me. 
1.14.0 PLM binding was working fine before the upgrade of OH to 2.5.0-1 from 2.4.0-1
openHAB is seeing the state change of the switches real time via the InsteonPLM.
I can turn on and off lights using the openHAB console so the 1.14.0 binding seems to be working???
This seems like a Hue Emulation issue but as I said before I confused.
Makes two of us.
I have noticed with others that have upgraded with 1.x bindings installed it lead to issues. That’s the reason I mentioned the post above. Will that solve the issue? Not sure but worth a shot.
If you’re will to try that I will search thru git for any open/closed issue that’s related.
@InTheDark Found several (9) open Hue issues.
EDIT:
@InTheDark: Post the output of /var/lib/openhab2/config/org/openhab/addons.config as I would like to check something in that file.
Removed the 1.x binding. Stoped openHAB Cleaned cache. Rebooted. Had to touch the insteon.items file again. Turned on legacy mode. Installed InsteonPLM binding.
Now when I ask Alexa to turn on a light she says OK and turns on a light but not the correct light. Ugh.
Had a switch that had not been added to Alexa so I tried to add it but Alexa responded with “…could not find any new devices…”
So removing the 1.x binding did have an effect.
What do you see in the logs when asking Alexa to turn on the light?
Did any of your configuration in the Hue binding change e,g, IP, port, etc…?
If I say Alexa to turn on Light A Alexa responds “OK” and turns on Light B
The log files show that Light B is being called for and not Light A.
Two thing you can try:
Change the names in your OH files e.g. swap light A and B
Delete the light in Alexa app and rediscover.
Second option may result in no light as device may not get rediscovered. I say that b/c you mentioned a new device that Alexa cannot find. Also, have you tried to reset the new device to see if that helps with Alexa finding it?
One more thing to do is set the log level to TRACE and post the output when trying to control via Alexa.
@InTheDark: If your feeling adventurous you can always give a new snapshot binding a try. Just found one that’s 3.0 and last updated today.
Uninstall current version of Hue then take just the jar file and place it in usr/share/openhab2/addons and restart OH.