There is still a known issue for setup with a lot of items that could still happen. It might be related but, if it worked before, not sure if it would be the case. One way to confirm would be to see if the second link returns a truncated data structure or not.
It does not look truncated, based on looking at the JSON and since the Item count is correct (actually 1703). Instead of rolling back, I’ll try ripping out all of my Items except for a handful. Is there a way to get to the logs for the cloud service or AWS? I think you mentioned a while back that those are no longer available.
Yes, we had to decrease the log level to limit AWS resource usage. I could take a look if there are some errors generated from your request. I just need your location and the exact time including timezone you issued a discovery request.
Have you tried to disable your current Alexa configuration and just model a single switch to see if it can be discovered?
1 Like
I got it! 121 items in Alexa now and they can be repeatably deleted and rediscovered. It was just one OH Item that was messing things up, which is really weird because it has been around a long time and I used it very recently through Alexa. Meaning, it was discovered, I used it, something changed, I deleted everything from Alexa, rediscovered, and nothing could be found because of this Item.
String Mode "Mode [%s]" <house> (gPresenceAndMode) {alexa="ModeController.mode" [supportedModes="Morning,Day,Evening,Night,Late,Party,Sleep",ordered=false,category="OTHER"]}
With this Item in the .items file, nothing is discovered. Commenting out the metadata and saving the .items file allows all Items to be discovered. This Item had previously been discovered without issue.
In case it is helpful, the log a couple posts up has the times of a failure to discovery (EST).
1 Like
I had already taken a look based on these timestamps but didn’t see any errors generated around that time. So I wasn’t 100% sure of the timezone.
So the issue here is that you are using a mode (“day”) with a friendly name not allowed. Some code was recently added to prevent these names from being included in the discovery result but unfortunately introduced a bug where it still allows a mode with no defined friendly names to be sent out causing the silent failure. Previously, the skill would send the unsupported names which would explain why it worked before although I guess the relevant mode wouldn’t be available on the Alexa side I assume.
Update: Actually running a quick test rolling back that piece of code, a mode with friendly name set to “day” actually works. I am planning to do some more testing and most likely roll it back. Thanks for helping identify this one 
1 Like
Very cool! I removed “Day” and my Mode Item was discovered by Alexa again! It would be great if you could get it added back in. Thank you!
That’s the plan.
1 Like
@5iver I just pushed a change to the live skill that only restrict the not allowed friendly names to capability resources only. Any mode or preset resource names will not be subject to that restriction. Your use-case should be discoverable again.
1 Like
Confirmed! Removed it from Alexa, added Day mode into the .items file, rediscovered and it was now found. Thank you!
1 Like
Sorry to jump into this discussion with an off topic question, but I started a new thread and haven’t received any help. I see that you have Insteon fanlincs working in your environment and wondered if you might be able to help. I have 2 fanlincs and when I enter them as items in OH2 with the #fan feature, I get errors stating that my item references an unknown feature. Is there anything special that needs to be done to get the fan control working? Here is my item entry and the log errors. Any help would really be appreciated. Thank you.
Number GuestfanLincFan “Guest fanlinc fan” {insteonplm=“XX.XX.XX:F00.00.1C#fan”}
[ERROR] [g.insteonplm.InsteonPLMActiveBinding] - item MasterfanLincFan references unknown feature: fan, item disabled! Known features for F00.00.1C are: dimmer, fastonoff, lastheardfrom, ledbrightness, manualchange, onlevel, ramprate.
Is it possible to ask Alexa “What is current power consumption?” and have her reply by reading value in openhab provided by electricity meter via modbus? Below is the item.
Number PowerTotal “PowerTotal [%.1f]” (gCharts) {channel=“modbus:data:endpoint:inputRegisters1:powtot:number” }
You can setup non controllable devices, for the sole purpose of getting its status, with any of the Building Block APIs controllers.
Number PowerTotal "Total [%.1f]" (gCharts) {alexa="RangeController.rangeValue" [friendlyNames="Power Consumption", nonControllable=true], channel="modbus:data:endpoint:inputRegisters1:powtot:number"}
thanks, it works. How to specify unit - watt?
This unit is not supported as of yet on the Alexa side. So you won’t be able to define a unit on this one.
3 Likes
@digitaldan I have read about using window contacts and motion detection sensors in alexa routines (https://stadt-bremerhaven.de/so-erinnert-euch-alexa-an-geoeffnete-fenster/)
I’m missing this with my items in the Alexa App. Is it a miss-configuration on my side or a missing feature in the Alexa Smart Home Skill? (I’m on openhab 2.5.1).
Unfortunately, as mentioned in the contact and motion sensor documentation, these cannot be used to trigger Alexa routines for the time being. Currently, the only support for these is requesting their state via voice commands.
Hi All,
Is this tagging incorrect? The item is discovered but it finds it as a switch, not a light which is odd.
Dimmer EnsuiteCeilingDim1 "Ensuite [%d %%]" (Group_HabPanel_Dashboard,gAllDimmers) { mqtt="<[broker:/house/out/EnsuiteCeilingDim1/state:state:default], >[broker:/house/in/EnsuiteCeilingDim1/command:command:*:default]", alexa="PowerController.powerState,BrightnessController.brightness" }
You can either use the Lighting metadata label or define the endpoint as a light by adding the meta parameter category="LIGHT".