You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -57,6 +58,24 @@ authenticate with a non-default state storage
57
58
# authentication and other useful data is now stored in the defined location instead of ~/.config/python-cozify/python-cozify.cfg
58
59
# you could also use the environment variable XDG_CONFIG_HOME to override where config files are stored
59
60
61
+
On Capabilities
62
+
---------------
63
+
The most practical way to "find" devices for operating on is currently to filter the devices list by their capabilties. The
64
+
most up to date list of recognized capabilities can be seen at `cozify/hub.py <cozify/hub.py#L21>`_
65
+
66
+
If the capability you need is not yet supported, open a bug to get it added. One way to compare your live hub device's capabilities
67
+
to those implemented is running the util/capabilities_list.py tool. It will list implemented and gathered capabilities from your live environment.
68
+
To get all of your previously unknown capabilities implemented, just copy-paste the full output of the utility into a new bug.
69
+
70
+
In short capabilities are tags assigned to devices by Cozify that mostly guarantee the data related to that capability will be in the same format and structure.
71
+
For example the capabilities based example code in this document filters all the devices that claim to support temperature and reads their name and temperature state.
72
+
Multiple capabilities can be given in a filter by providing a list of capabilities. By default any capability in the list can match (OR filter) but it can be flipped to AND mode
73
+
where every capability must be present on a device for it to qualify. For example, if you only want multi-sensors that support both temperature and humidity monitoring you could define a filter as:
By default queries to the hub are attempted via local LAN. Also by default "remoteness" autodetection is on and thus
111
+
if it is determined during cloud.authentication() or a hub.ping() call that you seem to not be in the same network, the state is flipped.
112
+
Both the remote state and autodetection can be overriden in most if not all funcions by the boolean keyword arguments 'remote' and 'autoremote'. They can also be queried or permanently changed by the hub.remote() and hub.autoremote() functions.
113
+
114
+
Using Multiple Hubs
115
+
-------------------
116
+
Everything has been designed to support multiple hubs registered to the same Cozify Cloud account. All hub operations can be targeted by setting the keyword argument 'hub_id' or 'hub_name'. The developers do not as of yet have access to multiple hubs so proper testing of multi functionality has not been performed. If you run into trouble, please open bugs so things can be improved.
117
+
118
+
The remote state of hubs is kept separately so there should be no issues calling your home hub locally but operating on a summer cottage hub remotely at the same time.
119
+
120
+
Enconding Pitfalls
121
+
------------------
122
+
The hub provides data encoded as a utf-8 json string. Python-cozify transforms this into a Python dictionary
123
+
where string values are kept as unicode strings. Normally this isn't an issue, as long as your system supports utf-8.
124
+
If not, you will run into trouble printing for example device names with non-ascii characters:
125
+
126
+
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 34: ordinal not in range(128)
127
+
128
+
The solution is to change your system locale to support utf-8. How this is done is however system dependant.
129
+
As a first test try temporarily overriding your locale:
130
+
131
+
.. code:: bash
132
+
133
+
LC_ALL='en_US.utf8' python3 program.py
134
+
89
135
Sample projects
90
136
---------------
91
137
@@ -98,7 +144,7 @@ Development
98
144
-----------
99
145
To develop python-cozify clone the devel branch and submit pull requests against the devel branch.
100
146
New releases are cut from the devel branch as needed.
101
-
147
+
102
148
Tests
103
149
~~~~~
104
150
pytest is used for unit tests. Test coverage is still quite spotty and under active development.
"""Set state storage path. Useful for example for testing without affecting your normal state. Call with no arguments to reset back to autoconfigured location.
53
53
54
54
Args:
55
55
filepath(str): file path to use as new storage location. Defaults to XDG defined path.
56
+
copy_current(bool): Instead of initializing target file, dump previous state into it.
56
57
"""
57
58
globalstate_file
58
59
globalstate
59
60
state_file=filepath
60
-
state=_initState(state_file)
61
+
ifcopy_current:
62
+
stateWrite()
63
+
else:
64
+
state=_initState(state_file)
61
65
62
66
defdump_state():
63
67
"""Print out current state file to stdout. Long values are truncated since this is only for visualization.
0 commit comments