Daikin Air Conditioner Not Showing All Properties

[aftertommy]

Once in a while I’ll find that my Daikin Air Conditioner appears in the list of devices, but it’s missing nearly all of its properties. It’s strange because I have several air conditioners of the same model, but it only happens with one or two of them.

[aftertommy]

Figured it out. Looks like my alias got mixed up with the base node profile.

[aftertommy]

Ah — perhaps this is a problem, then. I believe Daikin is using the same of for its nodeProfile and the air conditioner. I have an alias set up for this air conditioner’s id, but depending on the order the nodeProfile and ac are discovered, the alias gets matched to the wrong device. I want this alias to always be for the ac — matching to the nodeProfile is useless for me.

Is there some way to set up an alias to match against a specific device type?

[aftertommy]

Reattaching my logs. echonetlite2mqtt_logs_internalsStatus 5.zip

[aftertommy]

I think if the alias file changed to:

• id matches based on prefix. so for example “1234” would match the actual ids “1234” and “12345”
• add an eoj entry so that i can disambiguate. if i want the alias to be for an air conditioner, i can add eoj: “013001“ to the entry.

[banban525]

@aftertommy

Thanks for your reporting.

This is likely due to a change in v3.1.2 or v3.1.3.

Use v3.1.1 if you want to get the fix quickly.

The issue is how the ID is determined.

Sometimes ECHONETLite2MQTT fails to discover the device. This issue seems to happen if only the node profile is found initially.

[aftertommy]

Thanks! Yeah I believe it's just that the node profile is found first, then the ac is found after and assigned the separate ID. On my local, I ended up making my previously suggested change -- allow the alias file to define an optional eoj, and then change the parsing logic to include the eoj if it's defined, and compare the id using startsWith instead of just ===. It appears to work, but I'm not sure if that's the direction you want to go with. I suppose another way is to always assign nodeProfile devices a unique id, since I doubt alias files would ever want to alias those.

I wish I could provide a PR, but unfortunately my employer doesn't allow me to contribute to outside projects. Not really happy about that. In any case, I really love this project, and am truly appreciative of all your hard work.

[banban525]

Your idea of ​​partial ID matching is a good one.

This is still a prototype, but I am thinking of creating the following features. * is a wildcard.

Example: Specify id prefix and eoj

{
  name: "bedroom-aircon",
  id:"fe000008e84f25c6ce46*",
  eoj:"013001"
}

Example: Specify ip and eoj

{
  name: "kitchen-aircon",
  eoj:"013001",
  ip:"192.168.1.100"
}

However, the idea of ​​giving a special ID to a nodeProfile has problems. I have received reports of devices with duplicate IDs that are not nodeProfile.

https://github.com/banban525/echonetlite2mqtt/issues/32#issuecomment-2287957109

[aftertommy]

That schema sounds nice. It'd be interesting if adding ip entries in the alias file could replace the need for defining the ECHONET_DEVICE_IP_LIST environment variable.

[banban525]

Integrating the alias file and the environment variable ECHONET_DEVICE_IP_LIST... That would be a configuration file rather than an alias file.

Since this would be a specification change, I will address it in the next major version upgrade. However, there are no plans for a major version upgrade.

[banban525]

First, I will try to fix the method of determining the ID, which changed in the previous version.

I think the problem is that the ECHONET Lite specifications are vague. For a long time I've been struggling with how to give objects IDs.

ECHONET Lite has an ID specification, but it seems that the implementation differs depending on the manufacturer.

1. Each object (EOJ) has a different ID.
2. NodeProfile has an ID, but other objects have not.
3. All objects have the same ID.
4. Each object has the same ID, but only NodeProfile has a different ID.

(your air conditioner is 3.)

The fix I'm currently considering is one of the following:

• Delay deciding the ID until all devices are found.
• If devices are found later, change the already-determined ID.