AmazonEchoControl an Alexa "Air Conditioner" but smartHomeDevice channels are missing

[fmeili1 (Frank Meilinger)]

Hi,

I’ve installed a Senville SENL/24CD mini split unit with Alexa support and try to integrate it into my existing OpenHAB 3.4.4 system. Everything is up and running via Alexa App (on Android).

My amazonechocontrol OpenHAB binding is also already configured and I can control my Echo devices via OpenHAB since long time - but this will be my first non-Echo device to try to control via OpenHAB.

I’ve discovered the Alexa “Air Conditioner” device via amazonechocontrol discovery (with discoverSmartHome=3 in the bridge binding account settings) to get the required “device id” for the “smartHomeDevice” type.

I configure all my things and items via files (for testing and debugging I add sometimes temporarily a thing via UI just to find out the details how to configure it via file and remove it after this temporary test). My thing configuration looks like this:

Bridge amazonechocontrol:account:xxxx "Amazon Alexa (Amazon Account)" @ "Accounts" [discoverSmartHome=3, pollingIntervalSmartHomeAlexa=30, pollingIntervalSmartSkills=120]
{
...
  Thing smartHomeDevice senville24cd "Alexa Mini Split Senville SENL/24CD" @ "garage" [id="xxxx"]
...
}

Now I was able to see just ONE channel in the OpenHAB UI - the powerState (Switch) channel. I’ve configured it in my item file like this and it works without issues. Now I can switch the mini split on/off via OpenHab.

 Switch aGARV_AlexMiniSplit24CD_power "Alexa Mini Split Senville SENL/24CD power" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:powerState"}

The OpenHAB description shows that it may take more than 10 minutes to show all available channels because they are created dynamically.
But beside the Channel Type ID “powerState” (which was visible right away without wait time), no other channel is available in the UI to select - independent on how long I wait.

I’ve tried to use other channel Type ID’s which are listed in the documentation and which would make sense for an “Air Conditioner” (temperature, targetSetpoint, upperSetpoint, lowerSetpoint, thermostatMode) and just configured them in the items file.
But all of these (beside the working “powerState”) are showing NULL.

This is the used item file for the test:

Switch aGARV_AlexMiniSplit24CD_power "Alexa Mini Split Senville SENL/24CD power" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:powerState"}
String aGARV_AlexMiniSplit24CD_mode "Alexa Mini Split Senville SENL/24CD mode" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:thermostatMode"}
Number:Temperature aGARV_AlexMiniSplit24CD_temp "Alexa Mini Split Senville SENL/24CD temp" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:temperature"}
Number:Temperature aGARV_AlexMiniSplit24CD_upper "Alexa Mini Split Senville SENL/24CD upper" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:upperSetpoint"}
Number:Temperature aGARV_AlexMiniSplit24CD_lower "Alexa Mini Split Senville SENL/24CD lower" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:lowerSetpoint"}
Number:Temperature aGARV_AlexMiniSplit24CD_target "Alexa Mini Split Senville SENL/24CD target" {channel="amazonechocontrol:smartHomeDevice:xxx:senville24cd:targetSetpoint"}

In the Alexa App there are the following control options available which would be great to also have it in OpenHAB:

• power on/off (this is the only visible channel in OpenHAB and it already works, all following don’t work)
• temperature setting in fahrenheit
• fan speed (AUTO, LOW, MEDIUM, HIGH, TURBO)
• operation mode (AUTO, COOL, DRY, HEAT, FAN, SLEEP, TURBO)
• swing on/off (it’s for swinging the horizontal louver)

Is it possible to create channels manually in the amazonechocontrol binding? If yes, how may I found out the channel name and the possible values/options to use and set them? Maybe it’s possible to debug/check this on the Alexa side - but I could not find an answer?

Any help would be really appreciated.
Thanks in advance

[fmeili1 (Frank Meilinger)]

I’m still trying to understand how the amazonechocontrol binding is working for “smartHomeDevice” profile. The OpenHAB documentation states, that:

Note: the channels of smartHomeDevices and smartHomeDeviceGroup will be created dynamically based on the capabilities reported by the amazon server . This can take a little bit of time. The polling interval configured in the Account Thing to get the state is specified in minutes and has a minimum of 10. This means it takes up to 10 minutes to see the state of a channel. The reason for this low interval is, that the polling causes a big server load for the Smart Home Skills.

The Alexa App recognized the device as an AIR_CONDITIONER as the category. As of the Alexa documentation, an AIR_CONDITIONER device implements the following capability interfaces:

Alexa.PowerController
Alexa.ThermostatController
Alexa.ThemperatureSensor
Alexa.EndpointHealth
Alexa

My understanding is, that the OH amazonechocontrol binding maps these capabilities to well known OH channels which matches or makes sense for this device as described here. The following OH channels would make sense for an AIR_CONDITIONER smartHomeDevice:

temperature	Number:Temperature	R	smartHomeDevice	Temperature
targetSetpoint	Number:Temperature	R/W	smartHomeDevice	Thermostat target setpoint
upperSetpoint	Number:Temperature	R/W	smartHomeDevice	Thermostat upper setpoint (AUTO)
lowerSetpoint	Number:Temperature	R/W	smartHomeDevice	Thermostat lower setpoint (AUTO)
relativeHumidity	Number:Dimensionless	R	smartHomeDevice	Thermostat humidity
thermostatMode	String	R/W	smartHomeDevice	Thermostat operation mode

It looks like the dynamic channel generation for the binding is not working because (beside the powerState channel) it does not create the other channels based on the capabilities which should be reported by Alexa’s amazon server like documented.

I was not able to activate the debug or trace logging for the binding, even it shows the correct loglevel in the openhab command line client for the binding.

Any ideas how I may dig deeper into this issue?
Thanks!

[fmeili1 (Frank Meilinger)]

Still digging deeper and deeper into this problem.

Now I was able to activate TRACE logging for the binding and found that the binding really got the information from Amazon about the capabilities for the devices.

The binding does the following request:
2023-08-01 18:48:05.015 [DEBUG] [mazonechocontrol.internal.Connection] - Result of POST https://alexa.amazon.com/api/phoenix/state:...

Here is an excerpt of the TRACE log of the answer in the form “Updating {} with {}”:

Updating {

...
SmartHomeDevice{
	updateIntervalInSeconds = 30, 
	applianceId = 'AAA_SonarCloudService_xxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxx', 
	manufacturerName = 'Senville', 
	friendlyDescription = 'Senville Smart Air Conditioner', 
	modelName = '', 
	friendlyName = 'Mini Split', 
	reachability = 'null', 
	entityId = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', 
	applianceNetworkState = org.openhab.binding.amazonechocontrol.internal.jsons.JsonSmartHomeDeviceNetworkState$SmartHomeDeviceNetworkState@3a3410, 
	capabilities = [
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.RangeController', 
			properties = Properties{supported = rangeValue}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.RangeController', 
			properties = Properties{supported = rangeValue}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.PowerController', 
			properties = Properties{supported = powerState}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.ModeController', 
			properties = Properties{supported = mode}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.ToggleController', 
			properties = Properties{supported = toggleState}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.ModeController', 
			properties = Properties{supported = mode}}, 
		SmartHomeCapability{capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.EndpointHealth', 
			properties = Properties{supported = connectivity}}, 
		SmartHomeCapability{
			capabilityType = 'AVSInterfaceCapability', 
			type = 'AlexaInterface', 
			version = '3', 
			interfaceName = 'Alexa.ModeController', 
			properties = Properties{supported = mode}}], 
...

} with {

...
"namespace":"Alexa.ModeController",
"name":"mode",
"instance":"2",
"value":"1",
...
"namespace":"Alexa.ModeController",
"name":"mode",
"instance":"4",
"value":"2",
...
"namespace":"Alexa.ModeController",
"name":"mode",
"instance":"5",
"value":"1",
...
"namespace":"Alexa.PowerController",
"name":"powerState",
"value":"OFF",
...
"namespace":"Alexa.RangeController",
"name":"rangeValue",
"instance":"1",
"value":89.0,
...
"namespace":"Alexa.RangeController",
"name":"rangeValue",
"instance":"3",
"value":86.0,
...
"namespace":"Alexa.ToggleController",
"name":"toggleState",
"instance":"6",
"value":"OFF",
...

}

From my understanding Amazon send all required information to control the mini split.
In the Alexa App I can control the following parameters:

1. on/off
2. current room temperature (89 fahrenheit)
3. set temperature (in cooling mode max. 86 fahrenheit)
4. fan speed with 5 settings (AUTO, LOW, MEDIUM, HIGH, TURBO)
5. Operation Mode with 7 settings (AUTO, COOL, DRY, HEAT, FAN, SLEEP, TURBO)
6. Swing on/off for louver

Amazon reports 5 capabilities to the binding:

• two of Alexa.RangeController with properties “supported = rangeValue”
• one of Alexa.PowerController with properties “supported = powerState”
• three of Alexa.ModeController with properties “supported = mode”
• one of Alexa.ToggleController with properties “supported = toggleState”
• one of Alexa.EndpointHealth with properties “supported = connectivity”

I’ve enhanced the TRACE logging a little bit in the class org.openhab.binding.amazonechocontrol.internal.jsons.JsonSmartHomeCapabilities so that the properties values are printed with their values instead of their Java objectId’s like before.

The logging of these information is done in org.openhab.binding.amazonechocontrol.internal.handler.SmartHomeDeviceHandler in the method updateChannelStates().

My knowledge about the Alexa API is nearly zero and I also don’t know very much about the binding implementation itself. I’ve tried to understand how the current amazonechocontrol binding does the dynamic mapping from the Alexa capabilities to OpenHAB channels - but most parts are still not clear for me.

I still don’t know if the current behavior of the binding (to just show the on/off button as a channel) is correct and the other features are missing because they are not supported yet in OpenHAB OR if this is a bug in the binding and I should see the other channels in OpenHAB?

Maybe some could bring some light into this…

[fmeili1 (Frank Meilinger)]

Update!

Ok, I’ve found the reason why it’s not working in the bindings source code. The current version (4.x) of the OH amazonechocontrol binding does just not yet support the following Amazon Alexa smartHomeDevice interfaces:

• Alexa.ModeController
• Alexa.RangeController
• Alexa.ToggleController
  *… and maybe others which exists but which my mini split Alexa implementation does not use so far

The only supported interface which my mini split also uses is the Alexa.PowerController. That’s the reason why this is the only OH channel which I was able to use.

It would be great if these smartHomeDevice interfaces of Alexa would be supported in OH. My feeling is, that more and more appliances/devices offer Alexa support and it would help a lot to be able to integrate these devices in OH with via their existing Alexa support (because often there are no specific OH bindings available for such devices).
As far as I know, nearly all (cheaper?) mini split systems (e.g. Senville, MrCool, Della, etc.) are re-branded version build by the manufacturer “Midea”. So the chance is high to get all of these supported in OH via Alexa when this Alexa interfaces would be available in the binding.

I will try to submit a feature request for the amazonechocontrol binding and I would be happy to support the development.

[rpwong (Russ)]

@fmeili1

My feeling is, that more and more appliances/devices offer Alexa support and it would help a lot to be able to integrate these devices in OH with via their existing Alexa support (because often there are no specific OH bindings available for such devices).

I get what you’re saying, but this is tricky. Connecting through AmazonEchoControl is generally avoided due to the polling delay and the need for an Echo speaker to serve as a medium. If a device can be directly accessed through local IP or an API, that’s preferable to eliminate dependencies.

Which brings me to…

@fmeili1

As far as I know, nearly all (cheaper?) mini split systems (e.g. Senville, MrCool, Della, etc.) are re-branded version build by the manufacturer “Midea”.

Are you aware that there’s been work on a Midea binding? If Midea is rebranding units (similar to Tuya), I think your efforts would be much more valuable here.

New OH3 Binding - Midea Air Conditioning (LAN)

Hi All, please find new Openhab 3 binding for Midea Air Conditioning working in LAN: Releases Documentation Testing and contribution appreciated. Release notes (202102092117): Channel name convention change (i.e. operational-mode → operationalMode) Added description: Turbo mode works only for HEAT and COOL mode. Discovery changes. Connection keep alive fix. Swing mode: check first if works using IR Remote Controller, tested and it is working Release notes (202102101202): Discovery fix …

[fmeili1 (Frank Meilinger)]

@rpwong

I get what you’re saying, but this is tricky. Connecting through AmazonEchoControl is generally avoided due to the polling delay and the need for an Echo speaker to serve as a medium. If a device can be directly accessed through local IP or an API, that’s preferable to eliminate dependencies.

Mhh, are you sure about that a physical Echo speaker is really required? I’m only using the Alexa App on my smartphone to control the Alexa based smart devices - I never using Echo speakers to control these devices. The Alexa enabled WiFi devices which I use, are connected to my usual WiFi router (I can see the IP address and the MAC address of the mini split in my router configuration) and not to a specific Echo speaker. So in my understanding, the mini split is using the usual Amazon API on their cloud instance.

But in general you are right! I also don’t like the required cloud connect (because of security and possible delay problems, etc.) and I would prefer a local, non-cloud connection io OH for devices. I only used cloud based connections to OH when I’m not able to find a specific OH binding without cloud connect. So 99% of my devices are connected local to OH, even if they offer cloud connect. Examples are Shelly relays which I re-flash and using tasmota via MQTT to integrate into my OpenHAB.

But beside this, because the amazonechocontrol binding already exists and already supports the smartHomeDevice API’s (at least with some of the available methods), it would make the binding more useful if it would support the other important methods in this smartHomeDevice API also…

@rpwong

Which brings me to…

Are you aware that there’s been work on a Midea binding? If Midea is rebranding units (similar to Tuya), I think your efforts would be much more valuable here.

That’s a great information!!!

I’ve searched for a Senville mini split OH binding last week when I’d finished the unit installation and was not able to find one. At this time I was not aware that my unit was also a re-branded Mida device (I’ve learned it yesterday) and I’ve forgotten to search again for a specific Midea OH binding.

I will definitely give this Midea OH binding a try and I would prefer it’s use over the Alexa integration!

Thanks a lot for this information. It’s very valuable for me!

Frank

[rpwong (Russ)]

@fmeili1

Mhh, are you sure about that a physical Echo speaker is really required?

I guess not if you don’t have one. That’s how I read the documentation (long ago), but I don’t use Alexa. So I stand corrected.

@fmeili1

But beside this, because the amazonechocontrol binding already exists and already supports the smartHomeDevice API’s (at least with some of the available methods), it would make the binding more useful if it would support the other important methods in this smartHomeDevice API also…

Hey, If you’re interested in doing the work, I certainly won’t stop you. I guess the question is how often openHAB can access a device only through Alexa and by no other means…because those other means are almost certainly going to be more responsive.

Might be worth checking the SmarthomeJ version to see if there’s anything different going on there.

addons/bundles/org.smarthomej.binding.amazonechocontrol at 3.2.x ·...

But if this is the only thing you need Alexa for, then I definitely think you’re better off contributing to the Midea binding.