ROADMAP: Use Machine Readable Index for Pychonet 3.0

[scottyphillips-work]

The ECHONETLite Machine readable Appendix (MRA) provides a JSON formatted representation of ECHONETLite. In the second major redesign of this library, we could look up the MRA in order to parse data rather then trying to hand code objects all the time. Big job to redesign. But could be very worthwhile and save continued effort. Would also provide a built in JA translation for its natural domestic market. May also work better with Home Assistant.

https://echonet.jp/spec-en/#standard-08

MRA Structure The MRA provides: Definitions.json -> describes the format of echonetlite payloads.

• 'number' type
• 'state' types -> EDT codes to values such as 'on', 'off', 'auto', 'open' etc
• 'level' types -> sets a EDT base and describes the range. For example 'level_31-3' sets 0x31 as the base value and there can be up to 3 values (0x31, 0x32, 0x33)?
• 'raw' values -> EDT payload belongs to a range
• 'time' values -> EDT value represents a time
• 'bitmaps' -> representing a collection of values as bits.
• 'oneOf' -> either a state or a number.
• 'object' values -> combination of values (eg state + number). Alternatively it describes EDT payloads that are returning more then one value (eg R + T phase current). This can be nested objects.

Also provides devices, node-profile and superclassjson files. Payloads also can be described within objects, or in the definitions file.

Other considerations:

• the objects describe different versions of the spec. Nodes EPC values are type array rather then dict. EPC values can appear more then once to describe variations of versions.
• HomeAirConditioner uses values that do not necessarily align with HomeAssistant (eg. auto vs heat/cool), and so therefore a translation would be required.

One thing I am unsure of is the 'mcrules' files. (From release notes: The files in the folder MCRules are used to generate Device Descriptions for the ECHONET Lite Web API). Think these can be ignored.

Where I think version 3.0 will be different: There will be no more Python objects like 'HomeAirConditioner' etc and no more class-specific getters/setters. This is less of an issue to Home Assistant as it appears. Pychonet 2.0 currently uses class specific getter/setters merely as wrappers to setMessage and could be cleaned up out of the home-assistant custom component in preparation.

Design Changes:

• EchonetInstance will be where a lot of updates will be. The most complex logic will be around how to interpret EDT based on the JSON files. Probably need to use a recursive function to decode values that comprise of nested objects.

Example flow: 0x01:0x30 Home Air Conditioner. EPC: 0xA0

if type['data'] == 'oneOf':
    value = OneOf(self, edt)

def OneOf(EchonetLite, edt):
  array = EchonetLite.type['data']['oneOf']
  for each array value:
       test EDT against value
       if if value['type'] == state:
            test EDT against enum:
               if enum matches EDT value, return data (eg 0x41 return 'auto')
       if value['type'] == level
             test EDT against value range
             if within range return value. 
       return['unsupported value']

[nao-pon]

I also recently learned about MRA. I also think that this will contribute to greatly reducing maintenance costs in the future. I totally agree with supporting MRA!

[ammgws]

Might be able to get some additional ideas from projects such as https://github.com/banban525/echonetlite2mqtt