jens-maus / raspberrymatic Goto Github PK

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) or on a dedicated embedded device (RaspberryPi, Tinkerboard, IntelNUC, etc.)

Home Page: https://raspberrymatic.de

License: Apache License 2.0

Makefile 0.19% JavaScript 86.70% Shell 0.34% Batchfile 0.02% Tcl 5.82% HTML 3.51% C 0.05% C++ 0.24% CSS 2.77% NASL 0.04% Dockerfile 0.01% Perl 0.01% FreeMarker 0.08% Meson 0.03% SCSS 0.01% Python 0.22%

ccu buildroot homematic linux embedded-devices home-automation raspberrymatic operating-system smarthome tinkerboard raspberrypi elv-charly homematicip ccu3 virtual-appliance docker esxi iot kubernetes homeassistant

raspberrymatic's Introduction

– The alternative/free operating system for your homematicIP CCU

_{Deutschsprachiges 🇩🇪🇦🇹🇨🇭 ReadMe}

RaspberryMatic is a free and non-commercial open-source operating system alternative for running a cloud-free smart-home IoT central to provide connectivity to the homematicIP / HomeMatic hardware line of IoT devices developed by eQ-3 and distributed by ELV. RaspberryMatic has the aim to be 100% compatible to the vendor-developed HomeMatic CCU3 control central (CCU3) system. It can be directly installed on a CCU3 or ELV Charly hardware device. Alternatively, it can also be installed on a wide range of freely available single-board-computers (SBC) like a RaspberryPi, ASUS Tinkerboard, Hardkernel ODROID or even on full-fledged hardware platforms like an Intel NUC system. Furthermore, it can be run as a virtual appliance in modern virtualization environments (e.g. Proxmox VE, VirtualBox, Synology VMM, Docker/OCI, Kubernetes/K8s, vmWare ESXi, etc.) or even as a pure Home Assistant Add-On. On top of that wider range of supported operating environments, it also comes with exclusive features on different levels (WebUI, Linux OS, connectivity, etc.) to support end users with a more modern and advanced user experience compared to the vendor-provided CCU3 operating system.

more...

🍪 Features

Due to the used base components, RaspberryMatic is 100% compatibile to the standard CCU control center distributed by eQ3/ELV (CCU2/CCU3). This means, that not only it can use the same HomeMatic/homematicIP IoT hardware like a CCU3 central with the same base version. It also provides the same level of functionality in areas like the WebUI or Add-on compatibility. Furthermore, even system backups are compatible between the two CCU variants, which allows to easily switch between the vendor-provided CCU firmware and this free open-source based CCU system software.

On top of that, RaspberryMatic provides a whole bunch of enhancements or even bugfixes in the WebUI or underlying Linux operating system which are either not yet integrated in the official eQ3 CCU firmware or will never be integrated due to the functionality not being commercially interesting enough for eQ3/ELV.

more...

💻 Requirements

RaspberryMatic can be directly installed on the following, commercially distributed CCU hardware:

Hardware:

...or as a virtual appliance on the following virtualization environments:

Virtualization Environment:

more...

☁️ Quick-Start

Under Releases you will find dedicated images/files for each supported target hardware. Such an image is e.g. available as an RaspberryMatic-X.XX.XX.YYYYMMDD-XXX.zip download file. After having unarchived this file you should identify a *.img file which can be "flashed" to an adequate target media (sd card, usb-stick, ssd or virtual disk, etc.) using e.g. an imaging tool like Etcher. After having flashed this image on the target media you can then put it into your SBC or CCU3 hardware and boot the system. Depending on the used hardware, RaspberryMatic should then boot-up and try to identify the used HomeMatic/homematicIP RF-Module hardware potentially installed on the GPIO bus of your SBC. If this boot-up is finished, you should be able to access the standard WebUI in your local network by using the address http://homematic-raspi/ in your web browser. Afterwards you should then find yourself in then normal CCU WebUI where you can start configuring/using your HomeMatic/homematicIP IoT hardware.

more...

📝 Documentation (🇩🇪/🇺🇸)

😋 Support, Contributions

To provide general feedback or start discussions, please use either the Discussion fora in this GitHub project or (if you are german speaking) please contribute to the RaspberryMatic fora of the HomeMatic-Forum. If during discussions in these fora a definite and unique feature request or bug has been acknowledged by other RaspberryMatic users, please feel free to open a dedicated feature or bug fixing request in the issue tracker.

Any contribution in any way is highly welcome. Please feel free to contribute not only by using the official releases. If you have some time and free resources, we welcome any contributing to help to reproduce and perhaps even fixing any open issues in our issue tracker. Also participating in enhancing or fixing the official wiki-based documentation is appreciated. That's why any logged-in GitHub user can directly add and modify any documentation pages in this wiki.

On top of that, direct contributions by sending in PullRequests and source code contributions (Bugs, Features, etc.) are welcome. So if someone would like to see a certain feature implemented or bug fixed and has enough free resources and knowhow, please feel free to directly send in PullRequests using Git/GitHub. Please note, however, that any contribution to this open source project have to be in accordance to the Apache-2.0 open source license under which RaspberryMatic itself is developed and distributed. So by sending in PullRequests you will have to acknowledge that you are fine with the license implications of your contributions. Therefore, please refer to CONTRIBUTING as well as reading our CODE OF CONDUCT before you consider contributing to this project in any form.

more...

📜 Licenses

The RaspberryMatic project itself – the files in this repository – as well as the downloadable binary images in the Releases section are distributed under conditions of the open source Apache License 2.0 license, if not otherwise stated. RaspberryMatic itself is distributed completly free of charge and without any commercial intension whatsoever. Please note, that on top of the Apache-2.0 license, under which RaspberryMatic itself is distributed, other components (e.g. the underlying Buildroot/Linux Operating System) are distributed under different licenses. E.g. Buildroot/Linux itself is distributed under the GPLv2 which could have other implications when changing source parts or distributing own RaspberryMatic images. Furthermore, the eQ-3 OCCU components RaspberryMatic uses to provide the HomeMatic/homematicIP interconnectivity are re-distributed under the HMSL license terms. Furthermore, the RaspberryMatic logo and all other graphical image files in this repository and the downloadable binary images which are closely linked to this project are copyrighted by its sole authors. Any commercial and non-commercial (re-)use of these graphical image files or use of the RaspberryMatic logo are strictly prohibited when distributing own binary distributions or forked versions of RaspberryMatic.

Disclaimer of Warranty

All project contributors provide RaspberryMatic (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing RaspberryMatic and assume any risks associated with Your exercise of permissions under this License.

more...

📖 Literature

If after reading through this documentatin anyone is still unsure regarding the pros and cons of using RaspberryMatic rather than the standard vendor-provided CCU firmware or if someone would like to read / see more on which additional features RaspberryMatic provides, please see the following list of (mostly german speaking) literature:

👏 Acknowledgements

In addition to the whole list of Contributors which have contributed to the success of RaspberryMatic, we would like to explicitly thank the following list of people for their third-party contributions:

Alexander Reinert (@alexreinert) – for his low-latency generic_raw_uart kernel module which allows to use the eQ3 distributed RF modules (RPI-RF-MOD, HM-MOD-RPI-PCB) as well as for his HB-RF-USB, HB-RF-USB-2 and HB-RF-ETH open hardware projects providing USB and Ethernet based adapter PCBs to use the eQ3 RF modules with other base interfaces.

👪 Authors

Due to the large number of existing people having contributed to the success of RaspberryMatic, please refer to the Contributors accordingly.

🚧 ChangeLog

A detailed list of Changes between individual released versions can be reviewed through the Releases section of this GitHub project.

raspberrymatic's People

Contributors

Stargazers

Watchers

Forkers

eq-3-occu fusenigk tosa27 lietho85 hose63de olisim doityourway titusp burki24 drose28357 flashnizer tobiaskwf bikergp hmside rabbitmc marqus3 akwak2015 gluch hicksel kirschners koegel vonancken hobbyquaker jirmjos cpthein reissie2 ronnywyss pedromania auelth emartisoft msdigi methodus manfredherrmann fdeussen hoaloha nafets mkoch5 lady-ela psi-4ward gelmeraner mifricke mybugyourbug johlandabee pineapplemanuscript quickmic l4es kdambekalns anb0s zhangtao1987 libertyx82 sepalod fraatgit hoytron ralfdangel ahngoo8gongi heinog yazici julientant weissm yannik katschi jessman5 bennychou88 homie13 yungmichael andrej-83 bono1969 schoenims alexirion micst vman45 sebbo69 bluejoker108 bolzenhalter walburgf gmx168 jp112sdl olafkenfenheuer ed1954 angelnu toschko timtom2000 azreal1984 theimo1221 it-vbfk magnuspanter jomass wing350 maik2208 aventori loweer dalalsunil1986 masterwaster iotathome bja-engineering hsta alexreinert tostmann bubbadestroy m-a-r-c-o

raspberrymatic's Issues

Restoring a CCU-Backup results in non-working HmIP support

No matter if the source CCU had working HmIP support or no HmIP devices registered at all, as soon as a CCU Backup from a foreign CCU system (CCU2, YAHM, etc.) is restored teaching/registering new HmIP devices doesn't work anymore (even if a RaspberryPi2 with working HmIP support is used). It seems as some radio module device dependent ID is also restored with the backup which results in a state that the complete HmIP Support stops working even though HmIP is working on a freshly installed version of RaspberryMatic.

Compilation issue: gcc-4.9: fix build with gcc 6

Tried to create actual img on Fedora 25. Following error occurs.

In file included from ../../gcc/cp/except.c:1013:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined
Makefile:1058: recipe for target 'cp/except.o' failed
make[4]: *** [cp/except.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/home/devel/stb/code/homematic/RaspberryMatic/build-raspberrypi3/build/host-gcc-final-4.9.3/build/gcc'
Makefile:3972: recipe for target 'all-gcc' failed
make[3]: *** [all-gcc] Error 2
make[3]: Leaving directory '/home/devel/stb/code/homematic/RaspberryMatic/build-raspberrypi3/build/host-gcc-final-4.9.3/build'
Makefile:859: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/devel/stb/code/homematic/RaspberryMatic/build-raspberrypi3/build/host-gcc-final-4.9.3/build'
package/pkg-generic.mk:195: recipe for target '/home/devel/stb/code/homematic/RaspberryMatic/build-raspberrypi3/build/host-gcc-final-4.9.3/.stamp_built' failed
make[1]: *** [/home/devel/stb/code/homematic/RaspberryMatic/build-raspberrypi3/build/host-gcc-final-4.9.3/.stamp_built] Error 2
make[1]: Leaving directory '/home/devel/stb/code/homematic/RaspberryMatic/buildroot-2016.05'
Makefile:29: recipe for target 'dist' failed
make: *** [dist] Error 2

See: https://patchwork.openembedded.org/patch/122457/

GCC Version: gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
RaspberryMatic version: 1edcc34

WebUI device infos/settings doesn't show descriptive texts

For some devices the WebUI doesn't seem to show all information/settings like the CCU2 with the same release version. Here are some examples:

Here a HmIP shutter contact shown in the CCU2 (2.25.15):

The same shutter contact is shown in the current RaspberryMatic version like:

Note the difference in [STATE=1] and that the "Gewerk" is not correctly assigned in RaspberryMatic.

A similar problem occurs when trying to edit settings of this shutter contact:

CCU2 (2.25.15):

The same in RaspberryMatic:

Please note the SHUTTER_CONTACT_TRANSCEIVER settings which are descriptive in the CCU2 version.

Please also note that this issue seems to be present also for some normal BidCos-RF devices (like HM-ES-TX-WM) which displays its settings like:

Please note the POWERMETER_IEC type of lines which should be usually have descriptive texts instead.

Bluetooth support

We should evaluate how we can implement Bluetooth support (either through RaspberryPi3's Bluetooth chipset or via a dedicated USB-Bluetooth stick).

rewrite bcm2835-raw-uart kernel module to utilize device tree overlay

With help of the RaspberryPi developer community it should be possible to rewrite the HmIP required bcm2835-raw-uart kernel module in a way that it doesn't require own allocations for irq, iomem and clock rate.

See here for more information:
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=169800

This would essentially make the kernel module more generic so that future changes to the raspberrypi firmware/device tree would transparently work without having to change the kernel module itself. In addition, it would allow to directly use the kernel module without having to disable the pl011 serial module in the kernel config and thus should work with standard linux kernels like, e.g. Raspbian Linux provides.

Upgrade to latest buildroot version (2016.11)

In one of the next upcoming versions we should check if an update to one of the latest buildroot versions is easily possible without compromising stability.

Support for RaspberryPi2 (B)

Currently, the latest beta only supports the RaspberryPi3 hardware. It should be, however, relatively easy to also support the RaspberryPi2B platform which might only mean replacing some boot files in /boot according to the RaspberryPi model. It has to be seen if a common /boot directory layout can be maintained or separate *.img files have to be generated somehow.

RTC clock modules (PiFace Shim RTC, DS3231) fehlermeldung multimacd restarted

Hallo Jens,
Bekomme im Watchdog eine Fehlermeldung multimacd restarted alle 3 Minuten.
Davor lief alles nur die RTC Clock habe ich jetzt mit dran gemacht?

Vielleicht hilft dir das ja

Viele Grüße Charly

TODO: Missing packages

This ticket should serve as a reminder which packages/functionality is still missing in the current RaspberryMatic buildroot GitHub environment and that this have to be integrated before a new official public release:

Buildroot packages:

~~iptables/ip6tables~~
~~curl~~
~~i2cdetect/i2cdump, etc.~~
~~msmtp~~
~~rsync~~
~~wget (the internal busybox version not sufficient)~~
~~additional locales (de, etc.)?~~
~~tar (internal busybox version not sufficient)~~
ssdpd
~~ntpclient~~ (or use ntpd instead -> better option?!?)
~~/usr/bin/kmod (?)~~
~~/sbin/daemonize~~
/sbin/uevent
~~/usr/sbin/ifplugd, /usr/sbin/ifplugstatus, /etc/init.d/S45ifplugd~~

HomeMatic/CCU packages/binaries:

~~/bin/update_firmware_run, /bin/update_firmware_pre~~
~~/bin/setlgwkey.sh (/etc/init.d/S59SetLGWKey, /etc/init.d/S58LGWFirmwareUpdate)~~
~~/bin/setfirewall.tcl~~
~~/bin/setclock~~
~~/bin/setHWClock.sh~~
~~/bin/mountSD~~
~~/bin/dhcp_check.script~~
~~/bin/dhcp.script~~
~~/bin/checkDHCP~~
/bin/yaku-ns (?)
~~/etc/init.d/S50SetClock~~
~~/etc/udhcpd.usb0.conf~~
~~/etc/shadow is NOT a link to config/shadow~~
~~/etc/random-seed missing (?)~~
~~/etc/network/if-down.d/eQ3StopNetwork~~
~~/etc/network/if-up.d/eQ3StartNetwork~~
~~/config (what is this file for? added by accident?)~~
~~/lib/libfirewall.tcl~~
~~/lib/udev/rules.d/sd-cards-auto-mount.rules~~

As soon as we have resolved/added packages to our GitHub repo we will clear up this list.

Implement possibility to mount external devices (USB stick, USB HD, etc.)

The old CCU2-like functionality to mount an external microSD card doesn't work with RaspberryMatic anymore. We should check, however, if there might be an easy possibility to actually allow to automatically mount external drives once they are plugged in, including some functionality to recreate the filesystem. While this should be in principle possible, the usability is still questionable somehow. We should, however, still investigate the pros and cons about it and see if we could implement something like that.

WiFi support

We should evaluate how we can implement WiFi support (either through RaspberryPi3's WiFi chipset or via a dedicated USB-WiFi stick).

See here for more resources on WiFi support in buildroot:
https://github.com/danielnilsson9/buildroot-rpi3
https://delog.wordpress.com/2014/10/10/wireless-on-raspberry-pi-with-buildroot/
http://www.digitalpeer.com/blog/wireless-on-raspberry-pi-with-buildroot
http://www.walavalkar.co.in/home/wirelessrouterwithbuildrootandraspberrypi3
http://www.walavalkar.co.in/home/buildingalinuxfilesystemonraspberrypi3

Display RF-board serial number under WebUI->Help page

On a CCU2 the "Help" page usually shows the serial number. On RaspberryMatic no Serialnumber is displayed at all, but it would be good to actually display the RF-Board-Serialnumber instead.

Replace all "CCU2" terms in WebUI with "RaspberryMatic"

To better differentiate between a CCU2 and RaspberryMatic the WebUI should be patched to display "RaspberryMatic" everywhere where CCU2 is currently shown.

Docs about how to write Addons?

Hey,

thanks for this project. Initial installation worked like a charm.
I ask myself if there is any (technical) documentation for software engineers how to write addons?
I saw you have a few already, but i might want to do more features.

My current use case is to create a virtual smoke detector to be able to (reuse) the homematic smoke detectors as an alarm system.
In general i want to trigger them when i want + when fire is ongoing (this will be automatic).

FHEM supports this feature. See https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead

Any hint how to reach this?

Integrate direct support for RTC clock

We should directly integrate support (in terms of kernel modules and setup script) for the PiFace RTC clock as supported by the the hm-rtc (https://github.com/jens-maus/hm-rtc) CCU Addon package.

lighttpd runs out of file descriptors

I am running a build of the latest commit 013d96f on a Raspberry Pi 3 (with HMIP, working great so far).

I'm not sure about the cause for the problem, but every few hours, the webserver stops working. /var/log/lighttpd-error.log shows the line

2017-01-05 16:46:52: (server.c.1759) [note] sockets disabled, out-of-fds

Restarting the webserver fixes the problem. A single /etc/init.d/S50lighttpd restart will not work because one lighttpd process keeps running, blocking port 80. I have to /etc/init.d/S50lighttpd stop, identify and kill the hanging process, and then /etc/init.d/S50lighttpd start again.

An example output of lsof | grep lighttpd shows no unusual file desriptor count:

297     /usr/sbin/lighttpd      /dev/null
297     /usr/sbin/lighttpd      /dev/null
297     /usr/sbin/lighttpd      /dev/null
297     /usr/sbin/lighttpd      /var/run/lighttpd.pid
297     /usr/sbin/lighttpd      socket:[1187]
297     /usr/sbin/lighttpd      /var/log/lighttpd-error.log
297     /usr/sbin/lighttpd      anon_inode:[eventpoll]
297     /usr/sbin/lighttpd      /var/log/lighttpd-access.log

300     /usr/sbin/lighttpd      /dev/null
300     /usr/sbin/lighttpd      /dev/null
300     /usr/sbin/lighttpd      /dev/null
300     /usr/sbin/lighttpd      /var/run/lighttpd.pid
300     /usr/sbin/lighttpd      socket:[5188]
300     /usr/sbin/lighttpd      /var/log/lighttpd-error.log
300     /usr/sbin/lighttpd      anon_inode:[eventpoll]
300     /usr/sbin/lighttpd      /var/log/lighttpd-access.log

In this example, process 300 terminated gracefully using the init.d script, while process 297 had to be killed manually using kill 297.

As far as I can see, /etc/lighttpd/lighttpd.conf contains server.max-fds = 2048. I can't see how this value should ever be reached.

Integrate travis build test support

For automatic checks of our build environment we should use "travis" in future.

CCU-Historian requires JVM with libfontconfig and some bunch of sensible fonts

The CCU-Historian (www.ccu-historian.de) package doesn't currently generate trend graphics if used as a CCU Addon on RaspberryMatic. This is a result of the used Java JVM (Azul) which is a headless jvm version with bindings to libfontconfig. However, we are currently not using libfontconfig. I addition, RaspberryMatic should come with some standard set of fonts installed so that the JVM will be able to choose a proper font.

Version check refers to latest CCU2 firmware version instead of RaspberryMatic version

Currently, the version check under "Systemsteuerung->Zentralen-Wartung" always refers to the current CCU2 version available:

But we need to have an own version tag to check for the latest RaspberryMatic version. In addition, the current version refers to the git commit ID rather than to the 2.xx.xx version type.

/dev/watchdog missing

For proper hardware watchdog operations the kernel module that actually initialized /dev/watchdog needs to be automatically loaded upon system startup. This can be performed via:

modprobe bcm2708_wdog nowayout=1 heartbeat=15

However, we should first check if we can automatically load that module via mdev/udev rather than adding this mod probe line to a simply startup script. Furthermore, the /etc/init.d/S15watchdog startup script needs to be in place to actually start the watchdog daemon correctly.

$(ccuNotReady) shown in Webinterface during startup

Starting with 2.25.15.20170114 (beta4) of RaspberryMatic untranslated messages are shown if the Webinterface is accessed to early or if ReGaHss crashes and is thus unreachable. The messages shows $(ccuNotReady) instead of showing a translated/localized message for the user.

After analysing the problem, the issue seems to be related to the /www/error/error-503.html file being used to display the error page and which contains incorrect javascript locations compare to the error-500.html file that was used in previous releases of RaspberryMatic.

Resize /usr/local partition to maximum SD card size.

Currently, the size of the /usr/local partition is fixed to 2GB with automatic resizing of the ext4 filesystem. However, depending on the maximum SD card size we should introduce a mechanism that automatically resizes the /usr/local partition to the maximum SD card size and then generates a fresh ext4 filesystem on it.

Support for more different RTC GPIO module types

There exists more different RealTimeClock GPIO hardware modules than just the PiFace RTC clock which uses the MCP74xx chipset. In some future version we should enhance our RTC clock initialization routines to support other RTC clock modules (if possible).

One first potential candidate could be see here: http://homematic-forum.de/forum/viewtopic.php?f=65&t=34497&start=110#p328701

Remote syslog logging doesn't work

In the WebUI a user can specify an external syslog server to which log entries are being forwarded accordingly. This functionality doesn't seem to work yet.

Implement a graphical splash screen during boot

To improve usability by ordinary users psplash should be used to display a splash screen during bootup explicitly stating that bootup has succeeded and that a webbrowser should be used to access the WebUI.

Update Check checks for CCU2 updates and not for RaspberryMatic

The final version should not display update notifications for new CCU2 versions but rather check the version using the VERSION file in the top-level directory of our repository.

WebUI refers to "2.20.0" while OCCU version is at 2.21.10

The WebUI only refers to version "2.20.0" rather than "2.21.10" like this should be according to the latest OCCU version checkin. See here:

eq-3/occu#35

HmIP support not working on RaspberryPi3

While the current master branch has some basically working HomeMaticIP (HmIP) support, this seems to be only true when using a RaspberryPi2. Due to the different UART setups between RaspberryPi2 + RaspberryPi3 the required bcm2835-raw-uart kernel module seems to be currently unable to work correctly on a RaspberryPi3.

When booting the current RaspberryMatic SD card image a RaspberryPi3 stalls right after trying to run multimacd. After some investigation the issue seems to be due to bcm2835-raw-uart not accessing the hardware correctly. When disabling the multimacd startup and manually trying to use eq3configcmd update-coprocessor the following error occur:

# modprobe bcm2835-raw-uart
# eq3configcmd update-coprocessor -p /dev/bcm2835-raw-uart -c -se
2016/12/11 16:54:31.624 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/12/11 16:54:31.624 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2016/12/11 16:54:33.625 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/12/11 16:54:33.625 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2016/12/11 16:54:35.626 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2016/12/11 16:54:35.626 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2016/12/11 16:54:36.625 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application.

Here normally the serial number of the RF module should be returned (which works for a RaspberryPi2). Disabling the modprobe bcm2835-raw-uart line in /etc/init.d/S00eQ3SystemStartup and replacing it with modprobe amba-pl011 so that /dev/ttyAMA0 appears allows to perform a correct request for the serial number like:

# modprobe amba-pl011
# eq3configcmd update-coprocessor -p /dev/ttyAMA0 -c -se
2016/12/11 19:04:41.891 <Info> SerialNumber: MEQXXXXXXX

Please also note that the current master branch of RaspberryMatic uses the pi3-disable-bt overlay (see https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/board/raspberrypi3/config.txt#L31) to free the PL011 and turn off the Bluetooth module so that /dev/ttyAMA0 uses the PL011 like the RaspberryPi2 does. However, this unfortunately doesn't seem to immediately help for the bcm2835-raw-uart module.

/sbin/daemonize missing

For some applications it might be necessary/interesting to have /sbin/daemonize like this was provided with a CCU2. In RaspberryMatic beta3 it is, however, missing.

One application currently using it is, e.g. the Homeputer add-on package: http://www.contronics.de/download/homeputer-studio-software.html

See here for the current sources of demonize:
https://github.com/bmc/daemonize

Device Firmware Update Problems

The following reports points seem to point at some severe problems in trying to update certain device firmwares:

According to these reports the following devices seem to be affected:

HM-LC-Dim1TPBU-FM
HM-LC-Dimm1T-PL-3
HM-LC-Bl1PBU-FM

Symptoms always look quite similar:

Firmware Update doesn't succeed
Actuator stops in boot loader and is afterwards unusable anymore
Firmware Update can be continued/finalized using a restored Backup on a real CCU2

Homematic standard time control only triggers a few intervals and then stops

Before the move to RaspberryMatic I used a CCU2. I used the built in time control module in two programmes to trigger programme execution on a regular basis. The first programme calculated azimuth and elevation of the sun once per minute. The second programme set all heating groups to "auto" mode and "button lock" every night at 3am. This had worked flawlessly since I had bought CCU2 and just until the move to RaspberryMatic.

After the move to a rbpi2 the built in time control was broken. Upon saving a programme that was set to be triggered e.g. every 15 seconds the programme would be executed for approx. 3 intervals and then the timer would just stop. Loading and saving the programme again would re-trigger the cyclical execution, but again only for approx. 3 cycles.

As a result of this the time module (for me) is no longer usable under RaspberryMatic and I had to move to the (much more cumbersome) CUxD timer.

OSRAM Lightify coupling not possible

In the current 2.25.15 version the WebUI based coupling of OSRAM Lightify systems is not possible because the UI doesn't open and WebUI starts hanging. This needs to be fixed for a final 2.25.15 release.

Add IP adress to start up display on monitor

When RaspberryMatic starts up it shows a start screen at the HDMI output. When the boot prozess is finished it shows a logo an an url. A user has to copy this url to his browser by typing.

For debuging the router configuration in an multiple RaspberryMatic environment there should be an additional display of the actual ip adress (IP4 format xx.xx.xx.xx) or the max adress or both.

This is a minor feature request.

Remove root fs remount in S00eQ3SystemStart due to relinking /etc/shadow

Currently, /etc/shadow is linked to /usr/local/etc/config/shadow during initial System startup in /etc/init.d/S00eQ3SystemStart. While this perfectly works it is rather suboptimal as the rootfs should never be mounted rw. We should improve this for the final release, if possible.

See here:
https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/overlay/base/etc/init.d/S00eQ3SystemStart#L134-L140

Support for PREEMPT_RT real-time kernel patches

To improve kernel latency (and thus latency of the CCU) we should evaluate possibilities to actually use a full real-time linux kernel (with patches provided by https://rt.wiki.kernel.org/). At least the kernel config should have the normal low-latenty PREEMPT option enabled like in older RaspberryMatic kernel versions or with the kernel of the CCU2.

Use lighttpd package from buildroot and not from OCCU.

In the current git the lighttpd binary provided by the OCCU projects (https://github.com/eq-3/occu) is used rather than compiling/using an own build directly provided by buildroot. For convenience, and to more easier get security updates we should see if we can use the buildroot provided version instead.

Compatibility to CCU 2.25.15 firmware

For a next release of RaspberryMatic we should at least support compatibility to version 2.25.15 of the CCU firmware. For this, however, the OCCU repository (https://github.com/eq-3/occu) have to be updated to 2.25.15 as well. Please see the corresponding occu ticket for monitoring updates on that version (eq-3/occu#38).

NTP-Setup using /etc/ntpd.conf

We are already using the openntpd package in build root instead of the old ntpclient functionality. The NTP setup routines (WebUI, etc.) have to be adapted, however, to the new package so that users are able to change the ntp server address via the WebUI which should then trigger an automatic restart of the ntpd daemon.

dmesg: unhandled ioctl 0xXXXX output

Upon startup with HmIP support the eq3loop kernel module is dropping messages like the following:

[   68.542636] eq3loop: eq3loop_ioctl_slave() ttyS0: unhandled ioctl 0x5459
[   68.542689] eq3loop: eq3loop_ioctl_slave() ttyS0: unhandled ioctl 0x545D

It needs to be investigated if these messages are somewhat critical or not or if these ioctl calls can be easily supported by the eq3loop kernel module.

Upgrade to newer kernel versions (4.9.x, etc.)

The current master branch uses a special tagged version of the 4.4.x kernel line for RaspberryPi. We should revisit possibilities to upgrade to newer kernel versions in a future version of RaspberryMatic (as soon as we have implemented HomeMatic-IP support). See here for development on linux kernels for RaspberryPi: https://github.com/raspberrypi/linux

/bin/ssdpd missing

In beta2 of RaspberryMatic as well as on the CCU2 there is /bin/ssdpd which seems to be a UPnP/DLNA announcer. In OCCU itself there is no ssdpd binary nor any sources from which it seems to be compiled from. However, by searching on the net there seems to be some sources available http://netlab.linkpc.net/wiki/en:software:ssdpd:index which might be related to this.

HmIP Support

The current git sources still doesn't support HomeMatic-IP devices. For a proper integration a special kernel driver included in OCCU have to be compiled for the buildroot kernel and added accordingly.

See here for more info on that kernel module and why it hasn't been added yet:

eq-3/occu#33
eq-3/RaspberryMatic#1

Backup/Restore and Addon install not working for filled up /usr/local partition

The main backup/restore functionality in a CCU is using the /tmp partition to create a backup and to actually restore an old one. However, as /tmp is placed in Memory on RaspberryMatic and RAM is limited to 1GB on a Pi3 this can easily end up in a non-working backup/restore functionality if the user has installed large amount of data on /usr/local.

To fix this situation one has to rewrite the backup/restore functionality (found here: https://github.com/eq-3/occu/blob/master/WebUI/www/config/cp_security.cgi#L279) so that not /tmp is used but the backup/restore is performed on-disk (e.g. in /usr/local/backup) while checking if there is enough space.

The same applied for installing new CCU Addons in case the /usr/local partition is filled up too much.

WebUI: Missing error message after click on Install additional Software

(minor but existing fault)
Missing error message after click on "Zusatzsoftware installieren" while no file is selected (user fault hint)

Firmware update procedure requires to completely wipe SD card

Currently, upon a new RaspberryMatic release all users still have to completely wipe their SD card, update it with the next image and then restore a backup. This is quite cumbersome and error prone. For proper updates in future we should support normal "firmware updates" like this is currently possible for the old CCU2 hardware. For this, we have to lookup how this is currently done and how we can automatically generate similar "firmware update" archives users can then directly upload via the WebUI.

Stop booting at LGW Firmwareupdate

Hallo,
i have installed the newest build and it worked fine. I have tested basics and I was able to connect devices. Than I have restored settings from CC2 same build version as RasberryMatic. The System is now hanging at LGWF Firmwareupdate.

meine-homematic.de support

meine-homematic.de is currently not support per default.

Factory-Reset not working

Resetting RaspberryMatic via the WebUI provided "Factory-Reset" functionality doesn't work yet.

Fault in "Reboot-waiting-Screen"

CUxD devices no longer working after upgrade from beta3 to beta4

I ran RaspberryMatic beta3 on an rbpi2 and updated to beta4 by following the "official" process. I had the following plugins installed on beta3 during the backup process:
hm_pdetect, CUxD, XML-API
Restoring the backup under beta4 went flawlessly with one exception: My CUxD devices were still there but stopped working. I had two of those installed: One System-->Exec with id CUX2801001 (which I will just call exec) and one System-->Timer with id CUX2800001 (which I will just call timer).

The exec produced the following error log (CUxD console):

[1] homematic-raspi daemon.warn cuxd[599]: setValue 'CUX2801001:1.CMD_EXEC=tclsh /usr/local/setparam_virtdev.tcl INT0000004 WEEK_PROGRAM_POINTER int 1' not found!
[2] homematic-raspi daemon.info cuxd[599]: delete CUX2801001
[3] homematic-raspi daemon.info cuxd[599]: create CUX2801001 '' dtype=28&dtype2=1&dserial=1&dname=&dbase=10022&dcontrol=0'

What the script attempted to do (first log entry) was to set the data point WEEK_PROGRAM_POINTER of a virtual device (heating group) to 1. I suspect the actual command does not matter and any call to the exec would have failed ("not found"). As shown in the logs I then deleted the exec and created it again. The script has since been run several times and is working again.

The timer stopped working as well. It had lost all channel configuration (I actively use two timer channels). After having configured it again it still would not trigger the related programmes. So as with the Exec I removed and recreated the timer which corrected the issue.

The problem is that by removing CUxD devices they have to be added to all HM programmes again.

jens-maus / raspberrymatic Goto Github PK

raspberrymatic's Introduction

🍪 Features

💻 Requirements

☁️ Quick-Start

📝 Documentation (🇩🇪/🇺🇸)

😋 Support, Contributions

📜 Licenses

Disclaimer of Warranty

📖 Literature

👏 Acknowledgements

👪 Authors

🚧 ChangeLog

raspberrymatic's People

Contributors

Stargazers

Watchers

Forkers

raspberrymatic's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs