Updated external content (Jenkins build 270)

pull/1569/head
openHAB Build Server 2021-02-19 04:43:42 +00:00
parent 15870a6262
commit 1d577d005f
8 changed files with 107 additions and 38 deletions

File diff suppressed because one or more lines are too long

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.5 KiB

View File

@ -27,6 +27,10 @@ The latest versions have also implemented Z-Wave as transmission protocol which
<img src="doc/tellstick_duo.jpg" alt="Tellstick Duo with device" width="300px"/>
</p>
<p align="center">
<img src="doc/znet.jpeg" alt="Tellstick Znet lite v2" width="300px"/>
</p>
## Supported Things
This binding supports the following thing types:
@ -39,6 +43,7 @@ Additionally the binding have two types of bridge things which correspond to ava
* *Telldus Core Bridge* - Oldest API, used by USB devices. `telldus-core`
* *Telldus Live Bridge* - Telldus Cloud service, all devices with online access. `telldus-live`
* *Telldus Local Bridge* - Telldus Local API, Tellstick Net v2/Tellstick ZNet Lite v1/v2. `telldus-local`
***Switchbased sensors workaround***
@ -47,11 +52,12 @@ Additionally the binding have two types of bridge things which correspond to ava
## Discovery
Devices which is added to *Telldus Core* and *Telldus Live* can be discovered by openHAB.
Devices which is added to *Telldus Core*, *Telldus Live* and *Telldus Local* can be discovered by openHAB.
When you add this binding it will try to discover the *Telldus Core Bridge*.
If it is installed correct its devices will show up.
If you want to use the *Telldus Live* its bridge, *Telldus Live bridge* need to be added manually.
If you want to use the *Telldus Live* or *Telldus Local*, their bridges, *Telldus Live bridge* or *Tellstick Local*, needs to be added manually.
## Binding Configuration
@ -69,13 +75,13 @@ Use the option `repeat` for that. Default resend count is 2.
### Bridges
Depending on your tellstick device type there is different ways of using this binding.
The binding implements two different API:
Depending on your Tellstick device type there is different ways of using this binding.
The binding implements three different APIs:
**1)** *Telldus Core* which is a local only interface supported by USB based device. <br>
**2)** *Telldus Live* which is a REST based cloud service maintained by Telldus. <br>
**2)** *Telldus Live* which is a REST based cloud service maintained by Telldus.
**3)** *Telldus Local* which is a REST based local service maintained by Telldus.
<br>
> Not implemented yet but supported by some new devices, contributions are welcome. [API documention.](https://api.telldus.net/localapi/api.html) <br>
> **3)** *Local Rest API* is a local API which would work similar to Telldus Live but local.
Depending on your Tellstick model, different bridge-types are available:
@ -125,6 +131,36 @@ Optional:
- **refreshInterval:** How often we should contact *Telldus Live* to check for updates (in ms)
#### Telldus Local Bridge
To configure Telldus Local you need to know the local IP address of your Tellstick device and also request an access token.
Goto this page:
<https://tellstick-server.readthedocs.io/en/latest/api/authentication.html>
and follow steps 1), 2) and 3) to generate an access token.
In step 2) when you authenticate the application in your favorite browser, choose the options '1 year' and 'Auto renew access'.
Copy the 'token' returned in Step 3) and use that as accessToken in the local bridge config.
```
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImF1ZCI6IkV4YW1wbGUgYXBwIiwiZXhwIjoxNDUyOTUxNTYyfQ.eyJyZW5ldyI6dHJ1ZSwidHRsIjo4NjQwMH0.HeqoFM6-K5IuQa08Zr9HM9V2TKGRI9VxXlgdsutP7sg"
```
```
Bridge tellstick:telldus-local:3 "Tellstick Local ZWave" [ipAddress="x.y.z.w" , accesToken= "XYZ...W"]
```
Required:
- **ipAddress:** Local IP address of your Tellstick device
- **accessToken:** Access Token
Optional:
- **refreshInterval:** How often we should contact *Telldus Local* to check for updates (in ms)
## Channels
Actuators (dimmer/switch) support the following channels:
@ -209,6 +245,9 @@ Bridge tellstick:telldus-core:1 "Tellstick Duo" [resendInterval=200] {
Bridge tellstick:telldus-live:2 "Tellstick ZWave" [refreshInterval=10000, publicKey="XXXXXXXX", privateKey="YYYYYY", token= "ZZZZZZZZ", tokenSecret="UUUUUUUUUU"] {
sensor OutsideSensor2 [protocol="fineoffset",model="temperaturehumidity",name="temperaturehumidity:120",deviceId="120_temperaturehumidity_fineoffset"]
}
Bridge tellstick:telldus-local:3 "Tellstick Local ZWave" [ipAddress="192.168.50.17" , accesToken= "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImF1ZCI6IkV4YW1wbGUgYXBwIiwiZXhwIjoxNDUyOTUxNTYyfQ.eyJyZW5ldyI6dHJ1ZSwidHRsIjo4NjQwMH0.HeqoFM6-K5IuQa08Zr9HM9V2TKGRI9VxXlgdsutP7sg"] {
sensor OutsideSensor3 [protocol="fineoffset",model="temperaturehumidity",name="temperaturehumidity:120",deviceId="120_temperaturehumidity_fineoffset"]
}
```
### tellstick.items

View File

@ -20,14 +20,14 @@
<item-type>Number:ElectricPotential</item-type>
<label>AC Voltage</label>
<description>This phase's AC voltage relative to the next phase</description>
<state readOnly="true" pattern="%d %unit%"/>
<state readOnly="true" pattern="%.1f %unit%"/>
</channel-type>
<channel-type id="ac-voltage-to-n-type">
<item-type>Number:ElectricPotential</item-type>
<label>AC Voltage Phase To N Value</label>
<description>This phase's AC voltage relative to N line</description>
<state readOnly="true" pattern="%d %unit%"/>
<state readOnly="true" pattern="%.1f %unit%"/>
</channel-type>
<channel-type id="ac-power-type">

View File

@ -6,7 +6,7 @@
<bridge-type id="telldus-core">
<label>Telldus Core Gateway</label>
<description>This bridge represents the telldus center on a local computer.</description>
<description>This bridge represents the Telldus center on a local computer.</description>
<config-description>
<parameter name="libraryPath" type="text" required="false">
@ -25,7 +25,7 @@
</bridge-type>
<bridge-type id="telldus-live">
<label>Telldus Live Gateway</label>
<description>This bridge represents the telldus live cloud service.</description>
<description>This bridge represents the Telldus live cloud service.</description>
<config-description>
<parameter name="privateKey" type="text" required="true">
@ -34,12 +34,10 @@
<description>The private key from telldus</description>
</parameter>
<parameter name="publicKey" type="text" required="true">
<context>credentials</context>
<label>Public Key</label>
<description>The public key from telldus</description>
</parameter>
<parameter name="token" type="text" required="true">
<context>credentials</context>
<label>Access Token</label>
<description>The openauth token.</description>
</parameter>
@ -48,7 +46,7 @@
<label>Token Secret</label>
<description>The openauth token secret.</description>
</parameter>
<parameter name="refreshInterval" type="integer" required="false">
<parameter name="refreshInterval" type="integer" required="false" min="0" unit="ms">
<label>Refresh Interval</label>
<description>The refresh interval in ms which is used to poll Telldus Live.
</description>
@ -57,4 +55,27 @@
</config-description>
</bridge-type>
<bridge-type id="telldus-local">
<label>Telldus Local API</label>
<description>This bridge represents the Telldus local API.</description>
<config-description>
<parameter name="ipAddress" type="text" required="true">
<label>Local IP Address</label>
<description>The local IP address of the Tellstick.</description>
<context>network-address</context>
</parameter>
<parameter name="accessToken" type="text" required="true">
<label>Access Token</label>
<description>The access token.</description>
</parameter>
<parameter name="refreshInterval" type="integer" required="false" min="0" unit="ms">
<label>Refresh Interval</label>
<description>The refresh interval in ms which is used to poll Telldus local API.
</description>
<default>60000</default>
</parameter>
</config-description>
</bridge-type>
</thing:thing-descriptions>

View File

@ -9,6 +9,7 @@
<supported-bridge-type-refs>
<bridge-type-ref id="telldus-core"/>
<bridge-type-ref id="telldus-live"/>
<bridge-type-ref id="telldus-local"/>
</supported-bridge-type-refs>
<label>Dimmable Device</label>

View File

@ -8,6 +8,7 @@
<supported-bridge-type-refs>
<bridge-type-ref id="telldus-core"/>
<bridge-type-ref id="telldus-live"/>
<bridge-type-ref id="telldus-local"/>
</supported-bridge-type-refs>
<label>Sensor</label>
@ -91,14 +92,14 @@
<item-type>Number:Length</item-type>
<label>Rainrate</label>
<description>The current rain rate</description>
<state pattern="%d %unit%" readOnly="true"/>
<state pattern="%.1f %unit%" readOnly="true"/>
</channel-type>
<channel-type id="raintotal">
<item-type>Number:Length</item-type>
<label>Total Rain</label>
<description>Total rain</description>
<state pattern="%d %unit%" readOnly="true">
<state pattern="%.1f %unit%" readOnly="true">
</state>
</channel-type>
@ -126,9 +127,9 @@
<channel-type id="watt">
<item-type>Number:Power</item-type>
<label>Watt</label>
<description>Current kWatt</description>
<state readOnly="true" pattern="%f %unit%">
<label>Power</label>
<description>Current power</description>
<state readOnly="true" pattern="%.1f %unit%">
</state>
</channel-type>

View File

@ -284,12 +284,13 @@ This is the right time to prepare your system for disasters such as getting hit
Get an UPS.
Zram is enabled by default for swap, logs and persistence data.
You can toggle use in \[menu option 38\].
2. Move the root filesystem to USB-attached memory.
2. You can have openHABian mirror your SD card i.e. have it create a live copy. See [auto backup](#Auto-backup) documentation. You can activate mirroring using \[menu option 53\]
3. Move the root filesystem to USB-attached memory.
WARNING: USB sticks are as susceptible to flash wear-out as SD cards are, making zram the better choice for a standard Pi to run off its internal SD card.
But you can use this option to migrate your system to a safe medium such as an SSD or HDD.
See \[menu option 37\].
3. Use the openHAB integrated [openhab-cli tool](https://community.openhab.org/t/recommended-way-to-backup-restore-oh2-configurations-and-things/7193/82) to interactively backup/restore your openHAB **config** \[menu option 50/51\].
4. Use [Amanda Network Backup](http://www.amanda.org/) for full system backups, documentation [here](openhabian-amanda.md).
4. Use the openHAB integrated [openhab-cli tool](https://community.openhab.org/t/recommended-way-to-backup-restore-oh2-configurations-and-things/7193/82) to interactively backup/restore your openHAB **config** \[menu option 50/51\].
5. Use [Amanda Network Backup](http://www.amanda.org/) for full system backups, documentation [here](openhabian-amanda.md).
See \[menu option 52\].
Standard openHABian install enables zram by default (#1).
@ -386,23 +387,30 @@ Mind you that if you intend to open an issue, we need you to provide the output
#### Auto-backup
You might want to setup openHABian to automatically backup and mirror your internal SD card to an external unit.
We suggest to use another SD card in an external card writer device so that in case your internal SD card fails, you can switch SD cards to get the system back up running fast.
Note most "16GB" cards are not _exactly_ 16 GB and your new one mustn't have less bytes than the old one so openHABian enforces the second card to have at least twice the size of your internal card.
We make use of that extra space as storage for the backup system.
Auto backup is a marketing name for two distinct features that you can deploy in one go at *unattended* installation time on a RPi (when you deploy the image).
Technically it is a "low-cost" version of disk mirroring PLUS the setup of the Amanda backup system that has been available in a long time.
So don't let the name confuse you. If you didn't choose to set this up at installation time, you can also individually select these via openhabian-config` menu options 53 (mirroring) and 52 (Amanda).
Note mirroring is untested (and hardly makes sense to deploy) if you don't run RPi hardware but Amanda is well meant to be used as the backup system and is known to work on any hardware.
To setup right at installation time:
To setup openHABian to automatically backup and mirror your internal SD card to an external storage unit, we suggest to use another SD card in an external card writer device so that in case your internal SD card fails, you can switch SD cards to get the system back up running fast.
Note most "16GB" cards are not _exactly_ 16 GB and your new one mustn't have less bytes than the old one so openHABian enforces the second card to have at least twice the size of your internal card.
We can make use of that extra space as storage for the backup system.
To setup mirroring right at installation time:
Define `backupdrive=/dev/sdX` (replace X with the proper character) to enable this functionality right during unattended installation.
You may change `storagedir=/storage` to any other name.
The first attached disk type device is usually called `/dev/sda`.
openHABian will create partitions 1 and 2 to be mirrors of your internal card and will assign the remaining space to a storage partition.
Full mirroring will take place semiannually and for the 2nd partition (Linux root), changes will be synced once a week.
See `systemctl list-timers`, timers are defined in `/etc/systemd/system/sd*.timer`.
The unattended install routine will also setup Amanda to take daily backups and store them to that third partition.
Use `storagecapacity=xxx` to override how much space to consume at most for Amanda backup storage (in MB).
If you choose to skip this during system installation, you can still setup both, mirroring and Amanda, at any later time using the 5X menu options.
openHABian will create partitions 1 and 2 to be mirrors of your internal card and will assign the remaining space to another partition that you can use for storage.
NOTE: if you do and _if_ the remaining space is sufficient, selecting this will also result in setting up the Amanda backup system on that extra space.
Note you can change where it stores its backup data via `storagedir=/storage`, but you cannot unselect the Amanda setup at this stage.
If you want to setup mirroring only and Amanda anywhere else but on the extra SD space, you must not use unattended installation method (i.e. do not define `backupdrive`).
You can still setup both, mirroring and Amanda, separately at any later time using the 53 (mirroring) and 52 (Amanda) menu options.
Full mirroring will take place semiannually and for the 2nd partition (Linux root), changes will be synced once every day.
See `systemctl list-timers`, timers are defined in `/etc/systemd/system/sd*.timer`.
Menu 5X provides interactive access to the aforementioned functions:
`52 Amanda System Backup` will will prepare an existing directory as your backup storage and make Amanda launch once a day. See the separate [Amanda setup document](openhabian-amanda.md).
`53 Setup SD monitoring` prepares the partitions on an SD card and sets up timers to execute both, a full mirroring and complementary rsync 'diff' runs in a backup schedule.
`54 Raw copy SD` is a one-time raw copy (mirror) run.
`55 Sync SD` proagates (syncs) differences from your main SD card to your external card.
@ -526,16 +534,15 @@ I've just installed openHABian and now I'm confused.
No fancy login screen, no windows, no mouse support.
What did I get into?
You are not the first one to get confused about the **intended use case of openHABian**.
You are not the first one to get confused about the intended use case of openHABian.
Maybe it helps to not think of the RPi as a PC as we know it.
An RPi is not (well, not _necessarily_) to be used with a keyboard and display.
Its intended use case is to sit in a corner and provide a service reliably 24 hours a day, 7 days a week.
You already own a **powerful PC or Mac** to work on.
It would be a shame to have a powerful computer at your fingertips and then have to **restrict yourself** to a very limited graphical frontend on another device, wouldn't you agree?
You already own a powerful PC or Mac to work on.
What we actually want openHABian to be is a **dedicated, headless system** to **reliably run openHAB** and to **expose all interfaces** needed to interact and configure it (MainUI, HABPanel, openHAB LogViewer, Samba Network Shares, openHABian Configuration Tool, SSH, you-name-it).
If you know how to work with these interfaces, you are set for a way better experience than the alternatives.
The main challenge is to **get used to the Linux command line**, not even a GUI (like Pixel, see below) will relieve you from that in the long run.
The main challenge is to **get used to the Linux command line**, not even a GUI will relieve you from that in the long run.
If you are not willing to teach yourself a few fundamental Linux skills you will not become happy with any Linux system and should resort to a e.g. Windows machine.
However as you are willing to tinker with smart home technology, I'm sure you are ready to **teach yourself new stuff** and expand your experience.