Currently there is no further development for this adapter planned. Please migrate to ioBroker.ems-esp adapter which is maintained. If you miss any features at ioBroker.ems-esp open an issue at that repository (https://github.com/tp1de/ioBroker.ems-esp/issues).
IoBroker.km200 will stay available for some time, but keep in mind, that it will not be adapted to node 20 and upcoming js-controller v5.
The adapter supports the following heating systems:
For access to the systems code is used originally developed by Andreas Hahn and described in his blog entry here and entry there.
The heating system can be controlled via the Buderus website ([https://www.buderus-connect.de]) or by the 'EasyControl' app from your mobile phone. App and Buderus website also works with Junkers and Bosch heatings systems.
This has now succeeded in both directions and the adapter is already fully usable.
For this it is necessary to first install the app on a mobile phone and set a private password. The app asks for the device password and the login name off the device.
The adapter still needs the IP (or the network name, for example 'BuderusKM200.fritz.box') and the port address (Port 80 on the device, but if you changed it via a router ...).
If you add an '!' at the end of the address the adapter will work in debug mode and provide a lot of information!
Since the adapter must query the data from the system you must specify an update interval. This is set to a minimum of 5 minutes since every update requires a separate query.
You can use theblack / push list to hide or show certain data and reduce the number of states. This list consists of strings similar to RegExp (which they are conbverted to by the adapter) and the services in the heater are then filtered with them afterwards.
The syntax is that +
at the very beginning means that this field should not be skiupped, even if another rule would block it.
A -
is like nothing and caiuses the mathced state to be blocked.
each match is separated by ,
and can include /
or ^
for the beginning, *
which match everything and $
at the end to match the end.
The strings are case sensitive. If you like to know which states are found switch on debug mode and remove all blockings, then you will see all states created and can block some unneeded data with block list.
Examples: With +*temp*
you can fade in everything that contains 'temp' and with _Hourly$
you can block everything which has '_Hourly' at the end, both combined will block all _Hourly at end which do not have temp in their name.
An example list looks like /gateway*, /recordings*,*SwitchPrograms*,/HeatSource*, *HolidayModes*
and hides about 90 of ~ 180 records.
There are two other schedules available now, the fast (for states polled faster than every 30 minutes) and slow for states which are polled on hours or multihours cycles.
This allows you to track some information like temperatures in 1-5 minute cycles and other items in normal 20 minute cycles. The ones which usually dho not change even within an hour (like _Daily$ or _Monthly$ and several other general data) do not need to be read even every 30 minutes because they will not change. THis strategy helps to get faster readings for important data and slower readings for not so important.
The data for recording is (small) history data within the heating system. There are 3 different available: _Hourly, _Daily and Monthly. Hourly covers noprmally the last 48 hours. _Daily the last 2 month and Monthly not more than a year, all from current time of readout. Some data points do show less data points. You have to understand that the adapter collects the data from 3 individual calls for each recorded datapoint.
switchPrograms
can be read and written now as well, it's a JSON-String which reflects an Array of weekdays. Please don't change format, just the numbers when uploading. It seems the numbers are minutes that can be set only to 15 minutes increments.
Since V 1.1.2 the brackets and commas can be omitted and the blocked / pushed values can only be written with comma.
If you have entered the 64-character access-key you don't need the password, but it should not be left blank, just fill in anything.
/
or ^
first is for from beginning, *
can now be everywhere and $
can be the endswitchPrograms
are supported now for read and write!Adapter communication and retries more often to catch more errors.
Cleaning of objects / states for current adapters instance which are not part of scanned services anymore.
Have only 'request' and 'async' with --save now also registered in the package.json ... Remember: Nuícht --save forget :(!
Strings with allowedValues are now converted to ioBroker states in both directions (read & write)
Setting variables with numbers or strings now works. Thus, e.g. Target temperatures are changed. TODO: Enums and set tables
Adapter now works with blacklist and in read-only mode. TODO: Implement setting values in the heating system TODO: Implement variables with ENUMS (value lists)
First test
The MIT License (MIT)
Copyright (c) 2023 iobroker-community-adapters Includes code copyright (c) 2016-2019 Frank Joke (frankjoke@hotmail.com) Includes communications and crypto routines copyright (c) 2014 Andreas Hahn km200@andreashahn.info
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.