Installation completely fails

Adding a Hörmann VersaMatic P Gate door worked without any issues.

I could successfully program all codes in.

However, programming in a Hörmann SupraMatic E3 failed.

It’s state is singular: Opening, and persistent.

No other states are reported.

Malfunction Alarm says a lot (cynically): Malfunction!

However, the icon and the actions do actually a) show the correct door configuration (shows a picture being open or being closed, and a the right times), and the buttons do send a pulse also. It seems the programming cannot determine and just throws a Malfunction!. Since I am not allowed further diagnosis on the OS, I cannot diagnose the issue further.

That is one problem.

The 2nd problem is that Apple HomeKit integration does not work: de bridge can be seen and added. This adds 1 out of two devices, and is displayed as a window blind that can open and close. However, opening the blind does not change either state of Garage Door or Gate Door. Also, since the name and the icon are completely not related to the Garage Door or Gate, I cannot tell which device might have been attempted to add.

The 3rd problem is that Matter support does not work. When I try to enable it, a little circle just keeps turning. I waited a long time (like 30 minutes at least, but after a refresh it was clear nothing had been done.

So, Hörmann SupraMatic E3 is not working, HomeBridge is not working and Matter support is not working.

This little cube cost me 300 euro, so I would really appreciate an answer.

As a unix engineer, I am very much ready to assist further in any queries you may have. Also, feel free to access my cube remotely (at the condition I can do the same).

However, I have so ssh access, so I cannot diagnose much further.

Thank you for your patience, and if you read all the way to here: I’m very honored.

Sincerely,

Diederik CABRI

dcabri@gmail.com

Core Version: 2.40.2 (268ae103)
Web App Version: 2.40.1 (34403884)

„Send a message to support“ fails with a simple „could not send message“

Internet connected.
Remote access: connected
No Homeegrams, Plans or Scenario’s
No Groups.

@Steffen @Hoermann_KG_AST your turn.

2 „Gefällt mir“

In case you don’t get answer here next few days - write to
smarthome@hoermann.de

2 „Gefällt mir“

Meanwhile, I have done some troubleshooting at home, and at my neighbor’s.
Findings:

  • /etc/resolv.conf is having as default 127.0.0.1 for DNS resolving. That, obviously fails, but the logs are complaining and using the „good one“ anyway.
  • Doorways (both Gate and Garage) work well at my neighbor’s.
  • Only Garage doorway does not work for me:
    • goes always into alarm
    • I noticed some anomalies (I think) through the API :
      „id“: 46,
      „type“: 304, # CAAttributeTypeImpulse
      „state“: 3, # CANodeStateUpdateInProgress
      „id“: 50,
      „minimum“: 0,
      „maximum“: 4,
      „current_value“: 3.0,
      „type“: 135, # CAAttributeTypeUpDown
      „state“: 1, # CANodeStateAvailable
      „id“: 51,
      „current_value“: 1.0,
      „type“: 70, # CAAttributeTypeMalfunctionAlarm
      (I added the field descriptions)
  • My Garage door always goes into alarm, even when sending a simple pulse for „light“

So, I am inclined to think this has to do with the „weight“ the engine puts on the garage door.
You see: when you hold a garage door from closing, it displays an error - great!
When I don’t do that, the garage door still goes into error. I though this is reasonable deduction of mine, that maybe the engine would like the door to be „even closerder“ :wink:

Hoever, I am still wondering why the status stays „Opening“ (and never changes, whatever the door does, opening or closing), but the image and % statuses are updated correctly.
I also don’t understand what is keeping it in ‚Opening‘, when everywhere else one can see the status being updated. I should expect that after a few times going between 0 and 100%, open and closed, that status would eventually update also - but no.

The Apple Home app integration fails big time. But at least I gotten the API working (that was not easy), and the device is now connected to my HomeBridge system via this API. So, my server runs the HomeBridge doorways, and it receives and sends commands through the API that exists on the Homee Brain Cube.

A good enough solution for me (as my HomeBridge does not go into any alarm because there really is none - except maybe that the door „unexpectedly stopped“ when it could close no further. okay.

It was a difficult 72 hours, but now a working solution exists, yeey :wink:

Sincerely,

Diederik

Thank you, Kobolt.
As for smarthome@hoermann.de, I wrote them a week ago, they seem to be Brain Cube Dead :smiley: :smiley:
(aka I did not receive any answer yet…)
Well, where there’s no answer, there’s always hope. :smiley: :smiley: :smiley:

@Hoermann_KG_AST - lest ihr noch mit ?

2 „Gefällt mir“

I had some contact with Hörmann, but they propose only to bring my cube back for inspection.
As people in my house are now actually using this cube, this would signify a disruption of service for them. I proposed they send me another cube, test it (or let me test it), and see if there is any difference. But this proposal was dismissed, so we’re in a bit of a deadlock now.

I examined the diary.db and homee.db sqlite3 files, though.

diary.db shows in the table „Events“ something I think is unusual:

> sqlite> SELECT * FROM Events LIMIT 10;
> timestamp      eventType  eventID  causeType  causeIDGeneral  causeIDSpecific  eventValue
> -------------  ---------  -------  ---------  --------------  ---------------  ------------
> 1734357546174  302        3        40         3               6                0.0
> 1734357800706  306        0        0          0               0                0.0
> 1734357804817  302        3        40         3               6                0.0
> 1734360700977  302        3        40         3               6                0.0
> 1734360748129  302        3        40         3               6                0.0
> 1734360781680  3          2        0          0               0                1734447360.0
> 1734392283333  302        3        40         3               6                0.0
> 1734408546798  313        0        0          0               0                0.0
> 1734408566798  312        0        0          0               0                0.0
> 1734409369264  3          57       0          0               0                1.0

I think the 1734447360.0 is most probably a value that should not be there…

In homee.db, I saw in the Node table also discrepancy in the values:

> sqlite> SELECT * FROM Node LIMIT 10;
> nodeID  name                                           profile  image    status  statusChanged  routing  added       protocol  history  cube  note                                  services  phoneticName  security  owner  options
> ------  ---------------------------------------------  -------  -------  ------  -------------  -------  ----------  --------  -------  ----  ------------------------------------  --------  ------------  --------  -----  -------
> -1      homee                                          1        default  1       155            0        155         0         1        0                                           255                     0         0
> 1       H%C3%B6rmann%20Garagentor-Antrieb%20Serie%203  2015     default  1       1736766989     0        1734267908  19        1        17    %23%20H%C3%B6rmann%20SupraMatic%20E3  0                       0         2
> 2       H%C3%B6rmann%20Einfahrtstor-Antrieb            2010     default  1       1736766988     0        1734341781  19        1        17    %23%20H%C3%B6rmann%20RotaMatic%20P    7                       0         2

There is a value „7“ in the last row (which is the gate engines, working normally), but in the second to last entry, there is a value „0“ for that field in stead. I don’t know if that could point to something…

The folder /var/homee/rw/asteriadb is empty, I don’t know if that is normal.

So, the „stuck“ value seems to be „ATTRIBUTE_UPDOWN_VALUE_3“:„Opening“
But I don’t know why it is stuck, or where it is read from…

As said, everything is working as it should, just that the garage door is showing a wrong written label (always it says: „Opening“ whereas the icon and % display the right status (100% and closed icon), and a very annoying „!“ malfunction alarm when nothing is malfunctioning :smiley: ).
Also, the „Light“ button send the correct impulse, but in the app, the Light is always activated. However, in real life the light does actually go on and off.

If anyone could point me further where to look next, it would be very much appreciated :slight_smile:

In the automation I use, everything works fine, and gives good values, also through the API.
So, this is more annoyance and cosmetic than anything else…

Thank you so much!

1 „Gefällt mir“

How did you access the file system ?
And are you aware of @Micha debugging /support tool ?

Hello, Thank you for your request.
Getting access to the filesystem is rather easy, and described on the internet here. From there, activating the sshd daemon is also very easy. It’s great to have this versatility!
Having received little support, I decided I should at least check if there wasn’t anything I could do myself before calling for help.
No, I had never heard of @Micha debugging /support tool - I’ll check that one out now! :slight_smile:
Thanks for the hint!

1 „Gefällt mir“

@dcabri with Michas tool you can change a profile too if that’s helpful
Eg. change device type

The profile can only be changed if the device does not have one.

1 „Gefällt mir“

In any case great to know there is a root access, with some tools

@Steffen kannst du zu den oben genannten Hörmann Fragen Stellung nehmen?

Hello,

Thank you very much for the hint.
I tried the website today, and that website works great!!
It’s a very handy tool to have, indeed.
Most of its functionality I was able to get locally also.

Thanks again!

Unfortunately, it didn’t get closer to solving my issue.
But still: it’s a wonderful tool!

1 „Gefällt mir“