The pig in a poke

If there is one thing that all HomeMatic components together, it's the miserable documentation. This device, which is no longer the way out in HM product catalog since 2014 is in this regard, however, new negative standards. Even in user forums that provide usually much more detailed and reliable information than eQ-3 itself, can be found on the part only nebulous and exclusively obviously outdated information. Below I summarize the few together, I definitely can say (and this is after all, already a lot more than I could find connected at any point on the web):

- Operation on the CCU2 is no problem (if one disregards the deficiencies described below; which are probably independent of the hardware version of the CCU).

- All restrictions that are listed in offer texts about the device (no repeating of AES, no low-battery messages, incompatible with smoke detectors) are related to the firmware revision 1.1. However my purchased in June 2014 device had the Revision 1.2. Now it would be nice to know what has been improved here, but there are apparently not even a 1.2 Changelog. What I can say is that AES-encrypted transmissions are repeatet with standard System key under 1.2 readily. This suggests that probably also individual keys can be used; I have not tried it though. The other two restrictions, I can not say anything.

- Obviously, it is one of the devices that can not be updated via radio with the CCU (eQ-3 does this, so basically never have, but as an update definitely exists, but is not downloadable, you can as well quite safe be). Buyer it is therefore important to ensure that under no circumstances the firmware 1.1 or 1.0 is on the machine - which can never get comfortable down there.

- The assignment of the devices to be reinforced in the WebUI is solved miserably: The units are not identified by name, but only with serial numbers. So you can not help but to write off the numbers from the device list with pen and paper, so that they finds in the assignment list at all. If you want to strengthen direct links, you have serial numbers and channel assignments for both devices involved a note (especially hairy when heating Group).

- Any information about field strength etc. does not provide the equipment, also it generates obviously no own system messages and to make matters worse, not even auditable. If fault messages to devices so you do not know if the transfer from the device to the repeater, the repeater to the control panel, from the headquarters to the repeater or the repeater was disturbed about the device. Thus, the involvement of a gamble along the lines of trial and error - nice if it works, bad luck if not. That's just from the standpoint that doubles the number of possible sources of error by repeating, a real indictment.

Among all these aspects, it would be nice if you could recommend an alternative to this half-baked part. But you can not because it simply does not exist. In some cases (ie when the LAN reach far enough and only the Central radio traffic must be routed), you can optionally use the wireless LAN gateway. Basically, I would consider a better choice: At least there are not incompatibilities described, and also the establishment of the WebUI is somewhat decent. And - which I think is the most important feature - you get in devconfig RSSI values ​​for the connection quality of all devices to CCU (2) and to the gateway or the gateway displays, so it can on the basis of field strength decide which device routes better than the Gateway and which directly communicates with the CCU.
However, the Gateway latches (at least for me) without apparent reason once in a while to integrate times from the sale of fixed and is then only via central-restart. Something like diagnostically useful messages or Protokollierbarkeit there is also the gateway does not, so you have to experiment here. And furthermore the gateway is not able to strengthen direct connections. Whether it be worth the 30 euros extra cost compared to the repeater?

Last but still an important hint which may protect them from a bad buy if a HM device caused regular system messages about connection failures, you should determine first if not the appliance is faulty, so bring as far as possible the unit closer to the CCU (or check. as a "negative test" in devconfig whether the RSSI is less than Roundabout -90dBm. If that's the case, the wireless connection is at least slightly.). Only if the fault can be remedied by the fact, it may even make sense to the Repeater interpose. If the problem persists, you do not need a repeater, but should exchange the unit to be defective or has a "crooked" program in the CCU (typically recognizable fact that a device always performs action A always without error and action B with communication error - mostly no user error, but sloppiness by the manufacturer).
In any case, bring a repeater, which is used unless absolutely necessary, always at least the disadvantages of the circuit principle with him, by the provision of additional sources of error to Duty Cycle overruns.