This repository has been archived by the owner on Feb 14, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
/
__init__.py
executable file
·1688 lines (1276 loc) · 70.5 KB
/
__init__.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
#!/usr/bin/env python3
# vim: set encoding=utf-8 tabstop=4 softtabstop=4 shiftwidth=4 expandtab
#########################################################################
# Copyright 2020- Sebastian Helms Morg @ knx-user-forum
#########################################################################
# This file aims to become part of SmartHomeNG.
# https://www.smarthomeNG.de
# https://knx-user-forum.de/forum/supportforen/smarthome-py
#
# MultiDevice plugin for handling arbitrary devices via network or serial
# connection.
#
# SmartHomeNG is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# SmartHomeNG is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with SmartHomeNG. If not, see <http://www.gnu.org/licenses/>.
#
#########################################################################
"""MultiDevice-Plugin to interface different devices
The MultiDevice-Plugin (MD)
===========================
This plugin aims to support a wide range of devices which work by sending
commands to a device and reading data from it. By abstracting devices and
connections, most devices will be able to be interfaced by this plugin.
General description
===================
The whole MultiDevice-plugin is organized and abstracted into multiple levels
of (reference) base classes and derived classes handling special
implementations.
The plugin manages item association and updates. For each device it handles, it
creates an object based on ``MD_Device`` or derived classes.
The device object handles starting and stopping the device and its
configuration as well as connecting the different layers.
Possible commands are bundled by the ``MD_Commands`` class which handles
loading, validating and calling the separate ``MD_Command`` or derived
objects.
Each ``MD_Command`` object handles one command and is responsible for creating
command tokens/strings to/from the real device.
Each command is assigned a data type, which is represented by a ``Datatype``-
derived class and transforms values between the real device and the command
object respectively the final SmartHomeNG item data type.
To actually talk to the real device, that is, send commands/values and receive
replies, it uses a standardized interface via one of the ``MD_Connection`` or
derived classes.
Thus, the plugin, devices and commands are ignorant of physical connection
details, the connection implementation is transparent regarding actual data
structures or content, and only the datatype classes need to concern itself
with validity of data sent or received.
.. note::
Using the ``MD_Command_Str`` or especially the ``MD_Command_ParseStr`` classes,
the need for specialized datatype classes **can** possibly be sidestepped.
Be aware that while creating complex commands indeed can be fun, string
parsing will not be able to detect or cope with some data type conversions.
You have been warned 😉
(New) devices each reside in their respective subfolder of the plugin folder,
providing a derived device class, a device description file, a command definition
and - if applicable - additional necessary datatypes. These are automatically
loaded by the plugin if the respective device has a configuration entry in
``/etc/plugin.yaml``.
This concept is meant to
* minimize the amount of (repeating) code needed to implement a new device,
* make it easy to adjust functionality by deriving base classes, overriding
methods without needing to adjust the remaining code,
* reduce implementing a new device (mostly) to properly defining the
command API and datatypes,
* keeping individual devices separated and independent as each is loaded into
its own module / namespace.
This comes at the cost of needing to understand the architecture of the plugin
to be able to decide what to change/extend and what to keep.
My hope is that with proper documentation and examples, this last part is
easier to achieve than having to rewrite the whole handling code for items,
network, serial interfaces and commands every time.
Thanks to OnkelAndy for kicking my backside repeatedly; otherwise the
development of this plugin might have stalled before being able to run ;)
Base Classes
============
MultiDevice
-----------
The ``MultiDevice``-class is derived from the ``SmartPlugin``-class and provides
the framework for handling item associations to the plugin, for storing
item-command associations, for forwarding commands and the associated data
to the device classes and receiving data from the device classes to update
item values.
This class will usually not need to be adjusted, but runs as the plugin itself.
Standalone mode
~~~~~~~~~~~~~~~
In addition, the plugin has a - limited - capability to run as a standalone
program. The main goal is running device-supplied functions, for example to
initiate a device discovery or diagnostic functions. To this end, it must be
run from the SmartHomeNG folder by issuing
``python3 plugins/multidevice/__init__.py <devicename> [<params>] [-v]``
Be advised that any functionality any device shall provide in this mode must
absolutely by implemented by you :) (that is, the device developer).
struct.yaml generation
~~~~~~~~~~~~~~~~~~~~~~
The second goal of standalone usage is creating ``struct.yaml`` template files
from device command configuration. To this end, run the plugin with the ``-s``
or the ``-S`` argument:
``python3 plugins/multidevice/__init__.py <devicename> -s``
The ``-s`` argument prints the struct file contents to screen, ``-S`` causes the
plugin to write the ``struct.yaml`` directly to the devices folder. Beware that
existing files _will_ be overwritten.
The additional argument ``-a`` instructs the generator to add ``visu_acl:`` item
attributes, setting the value to ``ro`` or ``rw`` depending on the write property
of the respective command.
When starting, MultiDevice will create a struct ``multidevice.<device_id>.MODEL``
for each device. If a model is configured, this struct will contain the model-
specific struct; if a model is not configured, this struct will contain the
generic struct ('ALL').
MD_Device
---------
The ``MD_Device``-class provides a framework for receiving (item) data values
from the plugin and forwarding them to the connection class and vice versa.
A basic framework for managing the device, i.e. (re-)configuring, starting
and stopping the device is already implemented and can be used via by device
configuration without the need for code changes.
``MD_Device(device_type, device_id, **kwargs)``
Public methods:
* ``start()``
* ``stop()``
* ``send_command(command, value=None, **kwargs)``
* ``read_all_commands(group=0)``
* ``is_valid_command(command, read=None)``
* ``set_runtime_data(**kwargs)``
* ``update_device_params(**kwargs)``
* ``get_lookup(lookup, mode='fwd')``
* ``has_recursive_custom_attribute(index=1)``
* ``set_custom_item(item, command, index, value)``
Public callback methods:
* ``on_data_received(by, data, command=None)``
* ``on_connect(by=None)``
* ``on_disconnect(by=None)``
Methods possibly needed to overwrite for inherited classes:
* ``_set_device_defaults()``
* ``_post_init()``
* ``_transform_send_data(data_dict, **kwargs)``
* ``_transform_received_data(data_dict)``
* ``_send(data_dict)``
* ``_get_custom_value(command, data)``
* ``_process_additional_data(command, data, custom)``
* ``run_standalone()``
MD_Connection
-------------
This class and the derived classes provide frameworks for sending and receiving
data to and from devices via serial or network connections. For both hardware
layers implementation of query-response-connections and listening servers with
asynchronous push-to-callback are already available. If more complex
communication setup is needed, this can be implemented on top of the existing
classes.
Data is exchanged with ``MD_Device`` in a special dict format:
.. code:: python
data_dict = {
'payload': raw data as needed by the connection,
'data': data if not included in payload,
'kw1': additional 'keyword' args or data specific to the connection type,
'kw2': additional 'keyword' args or data specific to the connection type,
'...': additional 'keyword' args or data specific to the connection type,
}
``MD_Connection(device_type, device_id, data_received_callback, **kwargs)``
Public methods:
* ``open()``
* ``close()``
* ``send(data_dict)``
* ``connected()``
Public callback methods:
* ``on_data_received(by, data)``
* ``on_connect(by=None)``
* ``on_disconnect(by=None)``
Methods necessary to overwrite for derived classes:
* ``_open()``
* ``_close()``
* ``_send(data_dict)``
Methods possible to overwrite for derived classes:
* ``_send_init_on_open()``
* ``_send_init_on_send()``
This class has subclasses defined for the following types of connection:
* ``MD_Connection_Net_Tcp_Request`` for query-reply TCP connections
* ``MD_Connection_Net_Tcp_Client`` for persistent TCP connections with async replies
* ``MD_Connection_Net_Udp_Request`` for UDP listening server with async callback
* ``MD_Connection_Serial`` for query-reply serial connections
* ``MD_Connection_Serial_Async`` for event-loop serial connection with async callback
For detailed information and necessary configuration parameters, see the
respective class definition docstring.
MD_Protocol
-----------
For some device communication, the need arises to add another layer of protocol
handling - either for special handshake, initialization or general
communication and data handling, e.g. send queues or command tracking.
In these cases, instead of misusing the (physical) connection class or the
(command-oriented) device class, an additional protocol layer can be inserted
to handle this.
The ``MD_Protocol`` class is a subclass of ``MD_Connection`` and used by the
device instead of the actual connection class. The protocol class creates the
connection class instance itself and functions as a proxy.
To activate the protocol layer, configure the device with the ``protocol``
option, giving the name of an existing protocol class or the empty string for
the ``MD_Protocol`` base class, which has no additional function and can be
used for testing.
.. warning::
Supplying the ``protocol`` attribute as a kind of 'empty default' is
bound to break devices relying on protocol support.
The methods are the same as for the ``MD_Connection`` class.
This class has subclasses defined for the following types of protocols:
* ``MD_Protocol_Jsonrpc`` for JSON-RPC 2.0 protocol data exchange
* ``MD_Protocol_Viessmann`` for P300- and KW-protocol serial communication
MD_Commands
-----------
This class is a 'dict on steroids' of ``MD_Command``-objects with error checking
as added value. In addition, it also loads command and lookup definitions from
the file ``commands.py`` in the device folder and datatype sets and handles
datatype association.
No need to find out if ``command`` is defined, just call the method and the
class will handle failure cases. Beware of NoneType-return values, though.
``MD_Commands(device_type, device_id, command_obj_class=MD_Command, **kwargs)``
Public methods:
* ``is_valid_command(command, read=None)``
* ``get_send_data(command, data=None, **kwargs)``
* ``get_shng_data(command, data, **kwargs)``
* ``get_command_from_reply(data)``
* ``get_lookup(lookup, type='fwd')``
Options and syntax of commands configuration are detailed in the ``commands.py``
file in the ``dev_example`` folder:
.. literalinclude:: dev_example/commands.py
:language: python
MD_Command
----------
This class contains information concerning the command name, the opcode or
URL needed to issue the command, and information about datatypes expected by
SmartHomeNG items and the device itself.
Its contents will be initialized by the ``MD_Commands``-class while reading the
command configuration.
``MD_Command(device_id, command, dt_class, **kwargs)``
Public methods:
* ``get_send_data(data, **kwargs)``
* ``get_shng_data(data, **kwargs)``
* ``get_lookup()``
Methods possible to overwrite:
* ``get_send_data(data, **kwargs)``
* ``get_shng_data(data, **kwargs)``
* ``_check_value(data)``
This class has subclasses defined for the following types of commands:
* ``MD_Command_Str`` for string-based communication with device
* ``MD_Command_ParseStr`` ditto with attribute parsing and regexes
* ``MD_Command_JSON`` for JSON-RPC 2.0 commands with multiple arguments
* ``MD_Command_Viessmann`` for the binary Viessmann heating protocols
The classes ``MD_Command_Str`` and ``MD_Command_ParseStr`` are examples for
defining own command classes according to your needs. These examples utilize
strings and dicts to build request URLs as payload data e.g. for the
``MD_Connection_Net_TCP_Request`` or ``MD_Connection_Net_Tcp_Client`` classes.
They also demonstrate parameter substitution in command definitions on
different levels of complexity.
Datatype
--------
This class contains information about the data type and format needed by
a device and methods to convert its value from selected Python data types
used in items to the (possibly) special data formats required by devices
and vice versa.
Datatypes are specified in subclasses of Datatype with a nomenclature
convention of ``DT_<device data type of format>``.
All default datatype classes are imported from ``datatypes.py`` into the 'DT' module.
New devices can ship their own needed datatype classes in a file called
``datatypes.py`` in the devices' folder.
For details concerning API and implementation, refer to the reference classes as
examples.
``Datatype(fail_silent=True)``
Public methods:
* ``get_send_data(data, **kwargs)``
* ``get_shng_data(data, type=None, **kwargs)``
Methods necessary to overwrite:
* ``get_send_data(data, **kwargs)``
* ``get_shng_data(data, type=None, **kwargs)``
Configuration
=============
The plugin class is capable of handling an arbitrary number of devices
independently. Necessary configuration include the chosen devices respectively
the device names and possibly device parameter in ``etc/plugin.yaml``.
Every device is identified by its type (which corresponds to the device folder
dev_<type>) and its id, which is the internal SmartHomeNG handle and the name
used in item configuration. If only one device of the same type is used, type
and id can be the same. The ``devices:``-attribute in ``plugin.yaml`` contains
a dict of all configured devices where the id is the key and the configuration
for the specific device is provided as 'dict in value' format, if needed.
The configuration can include the attribute ``device_type`` to specify the type
of the device (if different from the id) and - optionally - the attribute
``model``, if a device offers multiple model configurations.
The item configuration is supplemented by the attributes ``md_device`` and
``md_command``, which designate the device id from plugin configuration and
the command name from the device configuration, respectively.
The device class needs comprehensive configuration concerning available commands,
the associated sent and received data formats, which will be supplied by way
of configuration files in python format. Furthermore, the device-dependent
type and configuration of connection can be set in ``etc/plugin.yaml`` for
each device used, if the provided defaults are not sufficient.
For some device classes, it is possible to choose from different models. In
this case, the attribute ``model: <modelname>`` should be present. In any
other case, the ``model`` key should not be present.
The connection classes will be chosen and configured by the device classes.
They should not need further configuration, as all data transformation is done
by the device classes and the connection-specific attributes are provided
from plugin configuration.
If the additional protocol layer is necessary, usually the device class will
provide for proper loading (it loads the protocol in place of the connection
class). If for some reason the protocol layer should be selected and loaded
manually, it can be forced by providing the ``protocol: <protocolname>``
attribute. As with the model, this attribute should normally not be present
in the configuration.
When starting, MultiDevice will create a struct ``multidevice.<device_id>.MODEL``
for each device. If a model is configured, this struct will contain the model-
specific struct; if a model is not configured, this struct will contain the
generic struct ('ALL').
So the easiest way to configure items is using the struct generator and including
the `MODEL`-struct for each device.
Three custom item attributes exist, aptly named ``md_custom1`` through
``md_custom3``. These can be used by the device for arbitrary functions.
Unlike other item attributes, these can be configured to be used recursively,
meaning that it only needs to be set for one item and is used for all sub-items.
To effect this behaviour, the device configuration takes the parameter
``recursive_custom: <foo>``, where <foo> can be a number from 1 to 3 or a list
of any combination of the three.
A list and short description of all currently supported attributes is found in
the ``MD_Globals.py`` file next to their respective identifiers.
Example for ``etc/plugin.yaml`` configuration:
.. code:: yaml
multidevice:
plugin_name: multidevice
devices:
- <type> # id = <type>, type = <type>, folder = dev_<type>
- param1: <value1> # optional
- <id>: # id = <id>, type = <type>, folder = dev_<type>
- device_type: <type>
- param1: <value1> # optional
- param2: <value2> # optional
- dev1 # id = dev1, type = dev1, folder = dev_dev1
- mydev: dev2 # id = mydev, type = dev2, folder = dev_dev2
- my2dev: # id = my2dev, type = dev3, folder = dev_dev3
- device_type: dev3
- device_model: foo # optional
- host: somehost # optional
- dev4: # id = dev4, type = dev4, folder = dev_dev4
- host: someotherhost # optional
New devices
===========
A new device_type ``gadget`` can be implemented by providing the following:
* a device folder ``dev_gadget``
* a device description file defining configuration attributes ``dev_gadget/device.yaml``
* a device configuration file defining commands ``dev_gadget/commands.py``
* a device class file with a derived class ``dev_gadget/device.py`` (this can be
an "empty" class containing only a ``pass`` statement)
* only if needed:
* additional methods in the device class to handle special commands which
do more than assign transformed item data to a single item or which need
more complex item transformation
* a data formats file defining data types ``dev_gadget/datatypes.py`` and
additional data types in the datatype file
* definition of lookup tables in ``dev_gadget/commands.py``
For examples on how to implement this, take a look at the dev_example folder
which contains simple examples as well as the reference documentation for the
commands.py file structure.
Also, take a look into the different existing device classes to get a feeling
for the needed effort to implement a new device. Both "simple" (all work is done
in the ``commands.py`` file) as well as more complex (extensive handling is added
in the ``device.py``file) devices are already provided and serve as examples.
Depending on the device protocol and command complexity, implementing a new
device can be a quick and easy job (e.g. for simple string or byte exchanges)
or requiring a more complex approach, e.g. if it is not practical to store all
information in items immediately, or if multiple data points are transmitted
at once, which requires splitting data or other means of data management.
"""
import importlib
import builtins
import logging
import re
import os
import sys
from copy import deepcopy
from ast import literal_eval
from collections import OrderedDict
__pdoc__ = {'multidevice.tools': False, 'multidevice.webif': False}
if __name__ == '__main__':
# just needed for standalone mode
builtins.MD_standalone = True
class SmartPlugin():
pass
class SmartPluginWebIf():
pass
BASE = os.path.sep.join(os.path.realpath(__file__).split(os.path.sep)[:-3])
sys.path.insert(0, BASE)
from MD_Globals import (sanitize_param, update, CMD_ATTR_CMD_SETTINGS, CMD_ATTR_ITEM_ATTRS, CMD_ATTR_ITEM_TYPE, CMD_ATTR_LOOKUP, CMD_ATTR_OPCODE, CMD_ATTR_PARAMS, CMD_ATTR_READ, CMD_ATTR_READ_CMD, CMD_ATTR_WRITE, CMD_IATTR_ATTRIBUTES, CMD_IATTR_CYCLE, CMD_IATTR_ENFORCE, CMD_IATTR_INITIAL, CMD_IATTR_LOOKUP_ITEM, CMD_IATTR_READ_GROUPS, CMD_IATTR_RG_LEVELS, CMD_IATTR_TEMPLATE, COMMAND_READ, COMMAND_SEP, COMMAND_WRITE, CUSTOM_SEP, INDEX_GENERIC, INDEX_MODEL, ITEM_ATTR_COMMAND, ITEM_ATTR_CUSTOM_PREFIX, ITEM_ATTR_CYCLE, ITEM_ATTR_DEVICE, ITEM_ATTR_GROUP, ITEM_ATTR_LOOKUP, ITEM_ATTR_READ, ITEM_ATTR_READ_GRP, ITEM_ATTR_READ_INIT, ITEM_ATTR_WRITE, PLUGIN_ATTR_CLEAN_STRUCTS)
from MD_Commands import MD_Commands
else:
builtins.MD_standalone = False
from lib.model.smartplugin import SmartPlugin
import lib.shyaml as shyaml
from .MD_Globals import (sanitize_param, update, CMD_ATTR_CMD_SETTINGS, CMD_ATTR_ITEM_ATTRS, CMD_ATTR_ITEM_TYPE, CMD_ATTR_LOOKUP, CMD_ATTR_OPCODE, CMD_ATTR_PARAMS, CMD_ATTR_READ, CMD_ATTR_READ_CMD, CMD_ATTR_WRITE, CMD_IATTR_ATTRIBUTES, CMD_IATTR_CYCLE, CMD_IATTR_ENFORCE, CMD_IATTR_INITIAL, CMD_IATTR_LOOKUP_ITEM, CMD_IATTR_READ_GROUPS, CMD_IATTR_RG_LEVELS, CMD_IATTR_TEMPLATE, COMMAND_READ, COMMAND_SEP, COMMAND_WRITE, CUSTOM_SEP, INDEX_GENERIC, INDEX_MODEL, ITEM_ATTR_COMMAND, ITEM_ATTR_CUSTOM_PREFIX, ITEM_ATTR_CYCLE, ITEM_ATTR_DEVICE, ITEM_ATTR_GROUP, ITEM_ATTR_LOOKUP, ITEM_ATTR_READ, ITEM_ATTR_READ_GRP, ITEM_ATTR_READ_INIT, ITEM_ATTR_WRITE, PLUGIN_ATTR_CLEAN_STRUCTS)
from .webif import WebInterface
#############################################################################################################################################################################################################################################
#
# class MultiDevice
#
#############################################################################################################################################################################################################################################
class MultiDevice(SmartPlugin):
""" MultiDevice class provides the SmartPlugin class for SmartHomeNG
This class does the actual interface work between SmartHomeNG and the device
classes. Mainly it parses plugin and item configuration data, sets up
associations between devices and items and handles data exchange between
SmartHomeNG and the device classes. Furthermore, it calls all devices'
`run()` and `stop()` methods if so instructed by SmartHomeNG.
It also looks good.
"""
PLUGIN_VERSION = '0.4.0'
def __init__(self, sh, standalone_device='', logger=None, **kwargs):
"""
Initalizes the plugin. For this plugin, this means collecting all device
modules and initializing them by instantiating the proper class.
"""
if not sh:
self.logger = logger
self.logger.info(f'Initializing MultiDevice-Plugin as {__name__}')
self._devices = {} # contains all configured devices - <device_id>: {'device_type': <device_type>, 'device': <class-instance>, 'logger': <logger-instance>, 'params': {'param1': val1, 'param2': val2...}}
self._items_write = {} # contains all items with write command - <item_id>: {'device_id': <device_id>, 'command': <command>}
self._items_read_all = {} # contains items which trigger 'read all' - <item_id>: <device_id>
self._items_read_grp = {} # contains items which trigger 'read group foo' - <item_id>: [<device_id>, <foo>]
self._commands_read = {} # contains all commands per device with read command - <device_id>: {<command>: [<item_object>, <item_object>...]}
self._commands_pseudo = {} # contains all pseudo commands per device (without command sequence) - <device_id>: {<command>: [<item_object>, <item_object>...]}
self._commands_read_grp = {} # contains all commands per device with read group command - <device_id>: {<group>: [<command>, <command>...]}
self._commands_initial = {} # contains all commands per device to be read after run() is called - <device_id>: ['command', 'command', ...]
self._commands_cyclic = {} # contains all commands per device to be read cyclically - device_id: {<command>: {'cycle': <cycle>, 'next': <next>}}
self._triggers_initial = {} # contains all read groups per device to be triggered after run() is called - <device_id>: ['grp', 'grp', ...]
self._triggers_cyclic = {} # contains all read groups per device to be triggered cyclically - device_id: {<grp>: {'cycle': <cycle>, 'next': <next>}}
self._items_custom = {} # contains item md_custom<x> attributes - <item_id>: {1: custom1, 2: custom2, 3:custom3}
self._sh = sh
self._webif = None
# Call init code of parent class (SmartPlugin)
super().__init__()
if sh:
# get the parameters for the plugin (as defined in metadata plugin.yaml):
devices = self.get_parameter_value('devices')
else:
# set devices to 'only device, kwargs set as config'
devices = {standalone_device: kwargs}
# iterate over all items in plugin configuration 'devices' list
#
# example:
#
# multidevice:
# plugin_name: multidevice
# devices:
# - dev1 # -> case 1, id = dev1, type = dev1, folder = dev_dev1
# - mydev: dev2 # -> case 2, id = mydev, type = dev2, folder = dev_dev2
# - my2dev: # -> case 3, id = my2dev, type = dev3, folder = dev_dev3
# - device_type: dev3
# - host: somehost
# - dev4: # -> case 4, id = dev4, type = dev4, folder = dev_dev4
# - host: someotherhost # handled implicitly by case 3
for device in devices:
param = {}
if MD_standalone:
device_type = device_id = device
try:
for (k, v) in devices[device].items():
param[k] = sanitize_param(v)
except Exception:
pass
else:
device_type = None
if type(device) is str:
# case 1, device configuration is only string
device_type = device_id = device
elif isinstance(device, OrderedDict):
# either we have devname: devid or devname: (list of arg: value)
device_id, conf = device.popitem() # we only expect 1 pair per dict because of yaml parsing
if type(conf) is str:
# case 2, device_id: device_type
device_type = conf
# dev_id: (list of OrderedDict(arg: value))?
elif type(conf) is list and all(isinstance(arg, OrderedDict) for arg in conf):
# case 3, get device_type from parsing conf
device_type = device_id
for odict in conf:
for arg in odict.keys():
# store parameters
if arg == 'device_type':
device_type = odict[arg]
else:
param[arg] = sanitize_param(odict[arg])
else:
self.logger.warning(f'Configuration for device {device_id} has unknown format, skipping {device_id}')
device_type = device_id = None
if device_id and device_id in self._devices:
self.logger.warning(f'Duplicate device id {device_id} configured for device_types {device_type} and {self._devices[device_id]["device_type"]}. Skipping processing of spare device type {device_type}')
continue
# did we get a device type?
if device_type:
device_instance = None
try:
# get module
mod_str = 'dev_' + device_type + '.device'
if not MD_standalone:
mod_str = '.' + mod_str
device_module = importlib.import_module(mod_str, __name__)
# get class
device_class = getattr(device_module, 'MD_Device')
# get class instance
device_instance = device_class(device_type, device_id, plugin=self, **param)
except ImportError as e:
self.logger.warning(f'Importing external module {"dev_" + device_type + "/device.py"} for device {device_id} failed, disabling device. Error was: {e}')
device_instance = None
if device_instance and not device_instance.disabled:
# create logger for device identity to use in update_item() and store in _devices dict
dev_logger = logging.getLogger(f'{__name__}.{device_id}')
# fill class dicts
self._devices[device_id] = {'device_type': device_type, 'device': device_instance, 'logger': dev_logger, 'params': param}
self._commands_read[device_id] = {}
self._commands_pseudo[device_id] = {}
self._commands_read_grp[device_id] = {}
self._commands_initial[device_id] = []
self._triggers_initial[device_id] = []
self._commands_cyclic[device_id] = {}
self._triggers_cyclic[device_id] = {}
dev_logger = None
# "alias" devices as class properties (prevent collisions)
if not hasattr(self, device_id):
setattr(self, device_id, self.get_device(device_id))
# check for and load struct definitions
if not MD_standalone:
self.logger.debug(f'trying to load struct definitions for device {device_id} from folder dev_{device_type}')
struct_file = os.path.join(self._plugin_dir, 'dev_' + device_type, 'struct.yaml')
raw_struct = shyaml.yaml_load(struct_file, ordered=True, ignore_notfound=True)
# if valid struct definition is found
if raw_struct is not None:
struct_list = list(raw_struct.keys())
self.logger.debug(f'loaded {len(struct_list)} structs for processing')
# replace all mentions of 'DEVICENAME' with the plugin/device's name
mod_struct = self._process_struct(raw_struct, device_id)
if param.get('model'):
mod_struct[INDEX_MODEL] = mod_struct[param['model']]
else:
mod_struct[INDEX_MODEL] = mod_struct[INDEX_GENERIC]
for struct_name in struct_list + [INDEX_MODEL]:
if struct_name in mod_struct:
self.logger.debug(f'adding struct {self.get_shortname()}.{device_id}.{struct_name}')
self._sh.items.add_struct_definition(self.get_shortname() + '.' + device_id, struct_name, mod_struct[struct_name])
if not self._devices:
self._init_complete = False
self.logger.info('no devices configured, not loading plugin')
return
# if plugin should start even without web interface
if sh:
self.init_webinterface(WebInterface)
def run(self):
"""
Run method for the plugin
"""
self.logger.debug('Run method called')
# hand over relevant assigned commands and runtime-generated data
self._apply_on_all_devices('set_runtime_data', self._generate_runtime_data)
# start the devices
self.alive = True
self._apply_on_all_devices('start')
def stop(self):
"""
Stop method for the plugin
"""
self.logger.debug('Stop method called')
# self.scheduler_remove('poll_device')
self.alive = False
self._apply_on_all_devices('stop')
def parse_item(self, item):
"""
Default plugin parse_item method. Is called when the plugin is
initialized. The plugin can, corresponding to its attribute keywords,
decide what to do with the item in future, like adding it to an
internal array for future reference
:param item: The item to process.
:return: Recall function for item updates
"""
def find_custom_attr(item, index=1):
""" find custom item attribute recursively. Returns attribute or None """
# self.logger.debug(f'looking recursively for {ITEM_ATTR_CUSTOM_PREFIX + str(index)} in {item} with {item.conf}...')
parent = item.return_parent()
# parent(top_item) is sh.items
if type(parent) != type(item):
# reached top of item tree
return None
if self.has_iattr(parent.conf, ITEM_ATTR_CUSTOM_PREFIX + str(index)):
return self.get_iattr_value(parent.conf, ITEM_ATTR_CUSTOM_PREFIX + str(index))
return find_custom_attr(parent, index)
# item is marked for plugin handling.
device_id = self.get_iattr_value(item.conf, ITEM_ATTR_DEVICE)
if device_id:
# is device_id known?
if device_id not in self._devices:
self.logger.warning(f'Item {item} requests device {device_id}, which is not configured, ignoring item')
return
device = self.get_device(device_id)
self.logger.debug(f'Item {item}: parse for device {device_id}')
command = self.get_iattr_value(item.conf, ITEM_ATTR_COMMAND)
# handle custom item attributes
self._items_custom[item.id()] = {1: None, 2: None, 3: None}
for index in (1, 2, 3):
val = None
if self.has_iattr(item.conf, ITEM_ATTR_CUSTOM_PREFIX + str(index)):
val = self.get_iattr_value(item.conf, ITEM_ATTR_CUSTOM_PREFIX + str(index))
self.logger.debug(f'Item {item} has custom item attribute {index} with value {val}')
elif device.has_recursive_custom_attribute(index):
val = find_custom_attr(item, index)
if val is not None:
self.logger.debug(f'Item {item} inherited custom item attribute {index} with value {val}')
if val is not None:
device.set_custom_item(item, command, index, val)
self._items_custom[item.id()][index] = val
custom_token = ''
if device.custom_commands and self._items_custom[item.id()][device.custom_commands]:
custom_token = CUSTOM_SEP + self._items_custom[item.id()][device.custom_commands]
if command:
# command found, validate command for device
if not device.is_valid_command(command):
self.logger.warning(f'Item {item} requests undefined command {command} for device {device_id}, ignoring item')
return
# if "custom commands" are active for device <dev>, modify command to be
# <command>#<customx>, where x is the index of the md_custom<x> item attribute
# and <customx> is the value of the attribute.
# By this modification, multiple items with the same command but different customx-Values
# can "coexist" and be differentiated by the plugin and the device.
command += custom_token
# from here on command is combined if device.custom_commands is set and a valid custom token is found
# command marked for reading
if self.get_iattr_value(item.conf, ITEM_ATTR_READ):
if device.is_valid_command(command, COMMAND_READ):
if command not in self._commands_read[device_id]:
self._commands_read[device_id][command] = []
self._commands_read[device_id][command].append(item)
self.logger.debug(f'Item {item} saved for reading command {command} on device {device_id}')
else:
self.logger.warning(f'Item {item} requests command {command} for reading on device {device_id}, which is not allowed, read configuration is ignored')
# read in group?
group = self.get_iattr_value(item.conf, ITEM_ATTR_GROUP)
if group:
if isinstance(group, str):
group = [group]
if isinstance(group, list):
for grp in group:
if grp:
grp += custom_token
if grp not in self._commands_read_grp[device_id]:
self._commands_read_grp[device_id][grp] = []
self._commands_read_grp[device_id][grp].append(command)
self.logger.debug(f'Item {item} saved for reading in group {grp} on device {device_id}')
else:
self.logger.warning(f'Item {item} wants to be read in group with invalid group identifier "{group}", ignoring.')
# read on startup?
if self.get_iattr_value(item.conf, ITEM_ATTR_READ_INIT):
if command not in self._commands_initial[device_id]:
self._commands_initial[device_id].append(command)
self.logger.debug(f'Item {item} saved for startup reading command {command} on device {device_id}')
# read cyclically?
cycle = self.get_iattr_value(item.conf, ITEM_ATTR_CYCLE)
if cycle:
# if cycle is already set for command, use the lower value of the two
self._commands_cyclic[device_id][command] = {'cycle': min(cycle, self._commands_cyclic[device_id].get(command, cycle)), 'next': 0}
self.logger.debug(f'Item {item} saved for cyclic reading command {command} on device {device_id}')
# command marked for writing
if self.get_iattr_value(item.conf, ITEM_ATTR_WRITE):
if device.is_valid_command(command, COMMAND_WRITE):
self._items_write[item.id()] = {'device_id': device_id, 'command': command}
self.logger.debug(f'Item {item} saved for writing command {command} on device {device_id}')
return self.update_item
# pseudo commands
if not self.get_iattr_value(item.conf, ITEM_ATTR_READ) and not self.get_iattr_value(item.conf, ITEM_ATTR_WRITE):
if command not in self._commands_pseudo[device_id]:
self._commands_pseudo[device_id][command] = []
self._commands_pseudo[device_id][command].append(item)
self.logger.debug(f'Item {item} saved for pseudo command {command} on device {device_id}')
# is read_grp trigger item?
grp = self.get_iattr_value(item.conf, ITEM_ATTR_READ_GRP)
if grp:
grp += custom_token
item_msg = f'Item {item}'
if custom_token:
item_msg += f' with token {custom_token}'
item_msg += ' saved for '
# trigger read on startup?
if self.get_iattr_value(item.conf, ITEM_ATTR_READ_INIT):
if grp not in self._triggers_initial[device_id]:
self._triggers_initial[device_id].append(grp)
self.logger.debug(f'{item_msg} startup triggering of read group {grp} on device {device_id}')
# read cyclically?
cycle = self.get_iattr_value(item.conf, ITEM_ATTR_CYCLE)
if cycle:
# if cycle is already set for command, use the lower value of the two
self._triggers_cyclic[device_id][grp] = {'cycle': min(cycle, self._triggers_cyclic[device_id].get(grp, cycle)), 'next': 0}
self.logger.debug(f'{item_msg} cyclic triggering of read group {grp} on device {device_id}')
if grp == '0':
self._items_read_all[item.id()] = device_id
self.logger.debug(f'{item_msg} read_all on device {device_id}')
return self.update_item
elif grp:
self._items_read_grp[item.id()] = [device_id, grp]
self.logger.debug(f'{item_msg} reading group {grp} on device {device_id}')
return self.update_item
else:
self.logger.warning(f'Item {item} wants to trigger group read with invalid group identifier "{grp}", ignoring.')
# is lookup table item?
table = self.get_iattr_value(item.conf, ITEM_ATTR_LOOKUP)
if table:
mode = 'fwd'
if '#' in table:
(table, mode) = table.split('#')
lu = device.get_lookup(table, mode)
item.set(lu, 'MultiDevice.' + device_id, source='Init')
if lu:
self.logger.debug(f'Item {item} assigned lookup {table} from device {device_id} with contents {device.get_lookup(table)}')
else:
self.logger.info(f'Item {item} requested lookup {table} from device {device_id}, which was empty or non-existent')
def update_item(self, item, caller=None, source=None, dest=None):
"""
Item has been updated
This method is called, if the value of an item has been updated by
SmartHomeNG. It should write the changed value out to the device
(hardware/interface) that is managed by this plugin.
:param item: item to be updated towards the plugin
:param caller: if given it represents the callers name
:param source: if given it represents the source
:param dest: if given it represents the dest
"""
if self.alive:
self.logger.debug(f'Update_item was called with item "{item}" from caller {caller}, source {source} and dest {dest}')
if not self.has_iattr(item.conf, ITEM_ATTR_DEVICE) and not self.has_iattr(item.conf, ITEM_ATTR_COMMAND):
self.logger.warning(f'Update_item was called with item {item}, which is not configured for this plugin. This shouldn\'t happen...')
return
device_id = self.get_iattr_value(item.conf, ITEM_ATTR_DEVICE)
# test if source of item change was not the item's device...
if caller != self.get_shortname() + '.' + device_id:
# from here on, use device's logger so messages are displayed for the device
dev_log = self._get_device_logger(device_id)