morg42 / multidevice Goto Github PK

Maybe have an option in the plugin settings.. that is True by default.

Low prio, aber vielleicht eine Idee..

Wenn ein Lookup für einen command angegeben ist, könnte es hilfreich sein, die dort enthaltenen Keys für den reply-token zu nutzen.
Beispiel, aktueller Denon Command Input für Zone 2 und 3. Dieser muss ganz nach unten in der Liste, damit nicht andere Replies, die mit dem gleichen String anfangen, falsch abgefangen werden (zB Z2PSBAS (\d{2}, Z2SLP(\d{3}|OFF), Z2(\d{2,3})).

'reply_token': 'REGEX', 'reply_pattern': 'Z2(.*)', 'lookup': 'INPUT'

Wenn das hier ginge..

'reply_token': 'REGEX', 'reply_pattern': 'Z2(MD_LOOKUP)', 'lookup': 'INPUT'

..und das so aufgelöst würde

'reply_pattern': 'Z2(<lookup1>|<lookup2>|<lookup3>)'

Ähnlich vielleicht auch valid_list oder valid_list_ci Angaben.

Aktuelle Lösung ist entweder eine sehr gefinkelte Regex oder das Hinunterschieben des commands an das Ende der Liste. Also kein Drama.

Not too important..
Currently when creating the struct and some additional items are created (e.g. using item_template or read_groups) those items get pushed to the beginning of the item tree. The original order is "broken".

ITEM_ATTR_CYCLE = 'md_read_cycle'
ITEM_ATTR_READ_INIT = 'md_read_initial' # trigger read on initial connect
ITEM_ATTR_GROUP = 'md_read_group' # trigger read with read group
ITEM_ATTR_READ_GRP = 'md_read_group_trigger'

is not very intuitive though most likely noone will ever care ;)
Still suggest:
ITEM_ATTR_READ_CYCLE = 'md_read_cycle'
ITEM_ATTR_READ_INIT = 'md_read_initial' # trigger read on initial connect
ITEM_ATTR_READ_GROUP = 'md_read_group' # trigger read with read group
ITEM_ATTR_READ_TRIGGER = 'md_read_group_trigger'

..and a bonus ;)
PLUGIN_ATTR_CLEAN_STRUCT = 'clean_structs'
->
PLUGIN_ATTR_CLEAN_STRUCTS = 'clean_structs'

CMD_ATTR_PARAM_VALUES should be obsolete, right? All references in imports, docue and e.g. line 588 in MD_Command.py might be killed? Inline docu of MD_Command_JSON needs update.

Not urgent at all... but...
Sometimes weird things happen that might stay uncovered.. ;)
Some basic check of the commands file might help here, e.g. are the lists and dicts at the correct position, etc.

Example:
When you forget (despite the plural name... ;)) that read_groups needs a list and only add one entry as dict, in the struct the item gets a child item called "item_attrs"

For sending as well receiving merging lookup tables doesn't seem to work.
Example device denon has an ALL and MODEL specific lookup for "input". Obviously only the model specific one is taken into account..

Feb 13 00:46:54 CET WARNING  plugins.multidevice.denon CP Server Thread-14 command zone1.control.input with value MPLAY produced error on converting value, aborting. Error was: Lookup of value mplay in table INPUT with entries {'phono': 'PHONO', 'cd': 'CD', 'aux2': 'AUX2'} failed, entry not found.  --  (MD_Device.py:send_command:260)

(log output modified to see content of lookup dict)

All read_cmds get triggered when triggering a read_group, recursively set md_custom1 are ignored.
Wanted behaviour: only those read_cmd with the same custom token should be triggered.

Sort of a special case (of course ;))...
When adding multiple command "sections" in the same hierarchy, e.g. tuner and general from denon, the read command/item gets overwritten and therefore doesn't trigger all read_cmds as expected.

Solution part 1:
put md_read_group_trigger values in a list when creating the struct. So when merging the structs by shng, the list gets merged (this works out of the box)

Solution part 2:
adjust the relevant parts in init.py make list out of single values and iterate through list

Variante 1:
Items mit Verweis auf nicht geladenen Command werden automatisch nicht ins Struct aufgenommen. Unteritems auch nicht.

Variante 2:
Items mit Verweis auf nicht geladenen Command werden nicht ins Struct aufgenommen, sofern es keine Unteritems gibt. Ansonsten werden sie ihren md_Einträgen beraubt und das nächste Hierarchielevel wird wieder gleich behandelt

Variante 3:
Definition, welche Structs für welches Model geladen werden sollen

Variante 4:
md_models Attribut, mit dem per Liste pro Item definiert werden kann, bei welchen Modellen das Item geladen werden soll. Sollte ein Unteritem einen vorhandenen Command haben, müsste wie in Variante 2 vorgegangen werden.

Andere Varianten?

'alarms': {'read': True, 'write': False, 'item_type': 'dict', 'read_cmd': '{CUSTOM_ATTR1} alarms 0 100 all', 'dev_datatype': 'SqueezeAlarms', 'reply_token': 'REGEX', 'reply_pattern': r'{CUSTOM_PATTERN1} alarms 0 100 all fade:\d+ count:\d+ (.*)', 'item_attrs': {'initial': True, 'read_groups': [{'name': 'player.control.alarms', 'trigger': 'query'}]}}

When creating the struct, this is correct:

ALL:
    player:
        control:
            alarms:
                type: dict
                ..

                query:
                    type: bool
                    enforce_updates: true
                    md_device: DEVICENAME
                    md_read_group_trigger: player.control.alarms.query

While the struct called "player" does not have the correct item tree

Nothing too important as it can be fixed by adding the relevant attributes manually. However..

'item_attrs': {'item_template': 'time', 'enforce': True, 'read_groups': [{'name': 'player.control.time_poll', 'trigger': 'poll'}]}
item_templates = {
    'time': {
        'poll':
            {
                'type': 'bool',
                'eval': 'True if sh....playmode() == "play" else None',
                'enforce_updates': True,
                'cycle': '5 = True',
                #'md_device': 'DEVICENAME', -> needs to be added manually
                #'md_read_group_trigger': 'player.control.time_poll' -> needs to be added manually
            }
    }

}

leads to missing read_group_trigger attributes for the "poll" item that is declared as the read_group trigger.

Low prio again ;)
While most situations can be handled with complex regexes it sometimes might be necessary or at least much more convenient to declare multiple regexes for one command.
Example..

(?:mode|playlist) (play|pause\s?\d?|stop)

having this option would be more convenient, maybe less error-prone:

['mode (MD_VALID_LIST_CI)', 'playlist pause (0|1)']