Homebridge plugin to integrate Tiko / Mon Pilotage Elec devices into HomeKit
The homebridge-tiko plugin allows you to control Tiko-connected heaters using Siri or the Apple Home app, by connecting the Tiko (a.k.a. Mon Pilotage Elec) platform to HomeKit through Homebridge.
This plugin allows you to do the following using Siri or the Home app on an iPhone, an iPad, an Apple Watch or a Mac:
- Display current and target temperature for each room
- Set target temperature for each room
- Put a heater in "frost", "absence", "boost" or scheduled mode
Guide d'installation et de configuration du plugin en français
- To use this plugin, you will need to already have:
- Node: latest version of
v18
orv20
- any other major version is not supported. - Homebridge:
v1.6
- refer to link for more information and installation instructions.
- Node: latest version of
Tiko modes cannot be displayed in the Home app because Homekit thermostat's state cannot be personalised. Here's the equivalence between an HomeKit instruction and a Tiko state:
Apple Home instruction | Tiko mode |
---|---|
Off (Éteint) | Frost (Hors-gel) |
Cool (Refroidir) | Absence |
Heat (Chauffer) | Boost |
Auto (Autom.) | Schedule (Programmation) |
- Install and configure Homebridge
- Search for "homebridge-tiko" in Homebridge's "Plugins" tab
- Install plugin
- Configure plugin by filling login (e-mail) and password
Endpoint defaults to https://particuliers-tiko.fr/api/v3/graphql/
but can be changed to
another url (eg. https://portal-engie.tiko.ch/api/v3/graphql/).
If your Tiko account is linked to multiple properties, homebridge-tiko
will use the first property by default. You can specify another property id
using the propertyId
option.
You can find the correct property id in the Tiko dashboard url:
https://particuliers-tiko.fr/dashboard/{propertyId}
Special thanks to paulchartres whose project hass-tiko helped me a lot to understand Tiko's Api without doing a lot of retro-engineering.
To develop Homebridge plugins you must have Node.js 18 or later installed, and a modern code editor such as VS Code. This plugin template uses TypeScript to make development easier and comes with pre-configured settings for VS Code and ESLint. If you are using VS Code install these extensions:
Using a terminal, navigate to the project folder and run this command to install the development dependencies:
npm install
Open the package.json
and change the following attributes:
name
- this should be prefixed withhomebridge-
or@username/homebridge-
, is case-sensitive, and contains no spaces nor special characters apart from a dash-
displayName
- this is the "nice" name displayed in the Homebridge UIrepository.url
- Link to your GitHub repobugs.url
- Link to your GitHub repo issues page
When you are ready to publish the plugin you should set private
to false, or remove the attribute entirely.
Open the src/settings.ts
file and change the default values:
PLATFORM_NAME
- Set this to be the name of your platform. This is the name of the platform that users will use to register the plugin in the Homebridgeconfig.json
.PLUGIN_NAME
- Set this to be the same name you set in thepackage.json
file.
Open the config.schema.json
file and change the following attribute:
pluginAlias
- set this to match thePLATFORM_NAME
you defined in the previous step.
TypeScript needs to be compiled into JavaScript before it can run. The following command will compile the contents of your src
directory and put the resulting code into the dist
folder.
npm run build
Run this command so your global installation of Homebridge can discover the plugin in your development environment:
npm link
You can now start Homebridge, use the -D
flag, so you can see debug log messages in your plugin:
homebridge -D
If you want to have your code compile automatically as you make changes, and restart Homebridge automatically between changes, you first need to add your plugin as a platform in ~/.homebridge/config.json
:
{
...
"platforms": [
{
"name": "Config",
"port": 8581,
"platform": "config"
},
{
"name": "<PLUGIN_NAME>",
//... any other options, as listed in config.schema.json ...
"platform": "<PLATFORM_NAME>"
}
]
}
and then you can run:
npm run watch
This will launch an instance of Homebridge in debug mode which will restart every time you make a change to the source code. It will load the config stored in the default location under ~/.homebridge
. You may need to stop other running instances of Homebridge while using this command to prevent conflicts. You can adjust the Homebridge startup command in the nodemon.json
file.
You can now start customising the plugin template to suit your requirements.
src/platform.ts
- this is where your device setup and discovery should go.src/platformAccessory.ts
- this is where your accessory control logic should go, you can rename or create multiple instances of this file for each accessory type you need to implement as part of your platform plugin. You can refer to the developer documentation to see what characteristics you need to implement for each service type.config.schema.json
- update the config schema to match the config you expect from the user. See the Plugin Config Schema Documentation.
Given a version number MAJOR
.MINOR
.PATCH
, such as 1.4.3
, increment the:
- MAJOR version when you make breaking changes to your plugin,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.
You can use the npm version
command to help you with this:
# major update / breaking changes
npm version major
# minor update / new features
npm version update
# patch / bugfixes
npm version patch
When you are ready to publish your plugin to npm, make sure you have removed the private
attribute from the package.json
file then run:
npm publish
If you are publishing a scoped plugin, i.e. @username/homebridge-xxx
you will need to add --access=public
to command the first time you publish.
You can publish beta versions of your plugin for other users to test before you release it to everyone.
# create a new pre-release version (eg. 2.1.0-beta.1)
npm version prepatch --preid beta
# publish to @beta
npm publish --tag=beta
Users can then install the beta version by appending @beta
to the install command, for example:
sudo npm install -g homebridge-example-plugin@beta
Consider creating your plugin with the Homebridge Verified criteria in mind. This will help you to create a plugin that is easy to use and works well with Homebridge. You can then submit your plugin to the Homebridge Verified list for review. The most up-to-date criteria can be found here. For reference, the current criteria are:
- The plugin must successfully install.
- The plugin must implement the Homebridge Plugin Settings GUI.
- The plugin must not start unless it is configured.
- The plugin must not execute post-install scripts that modify the users' system in any way.
- The plugin must not contain any analytics or calls that enable you to track the user.
- The plugin must not throw unhandled exceptions, the plugin must catch and log its own errors.
- The plugin must be published to npm and the source code available on GitHub.
- A GitHub release - with patch notes - should be created for every new version of your plugin.
- The plugin must run on all supported LTS versions of Node.js, at the time of writing this is Node.js v16 and v18.
- The plugin must not require the user to run Homebridge in a TTY or with non-standard startup parameters, even for initial configuration.
- If the plugin needs to write files to disk (cache, keys, etc.), it must store them inside the Homebridge storage directory.
Note these links are here for help but are not supported/verified by the Homebridge team