@Larx
Bei welchen Versionen funktioniert es denn?
Ich hatte hier die stable 0.7.48 als saubere Neuinstallation ohne irgendwelche Konfigurationsdaten.
Und dann die nightly 0.8.0-3128 über die 0.7.48 installiert. Bei beiden Fehlanzeige…
Da ich bislang ja nur 3 Devices zum Testen installiert habe könne ich ja noch mal bei Null anfangen.
Ich habe sowohl den CUBe (CUNX) als auch 2 verschiedene Raumthermostate und einen Wandthermostaten, sowie Gebäude und Räume über die Admin-UI eingerichtet.
Ich update alle paar Wochen das Docker-stable Image. Also 0.7.48. Hatte aber zwischendurch versehentlich auch schon mal wieder ein nightly eingespielt, was sich aber rückstandsfrei wieder downgraden ließ.
In meinem Fall hatte ich nur meine max.conf sowie die Homegear Datenbank gesichert und alles andere einfach von Grund auf neu aufgesetzt. Danach lief alles wieder problemlos und ich hatte keine Pairings verloren.
Ich hatte vorher versucht, die diversen Konfigurationsdateien durch Vergleich mit den Originalen von GitHub zu checken, habe aber dabei festgestellt, dass es da offenbar im Laufe der Zeit an der einen oder anderen Stelle Änderungen gegeben hatte. Auch an der Verzeichnisstruktur für das AdminUI passte etwas nicht.
Hi @Larx, ich habe derzeit den Nightly Build 0.8.0-3115 — Sagst du mir, dass ich alle Probleme mit Max! beheben werde, wenn ich die stabile Version 0.7.48 installiere? Können Sie mir genau sagen, welche Dateien ich aufbewahren muss? Vielen Dank
p.s.
Außerdem waren in der Benutzer-Benutzeroberfläche, in der ich noch nie Räume oder Geräte gesehen habe, die Registerkarten immer leer, auch wenn Räume und Geräte auf der Verwaltungsseite konfiguriert wurden … Am Ende kann ich Homegear nur verwenden, um das Wochenprogramm der Thermostate seit dem zu konfigurieren Die grafische Oberfläche ist sehr praktisch und für die Verbindung mit Homeassistant geeignet. Ich muss jedoch auch Homematic Manager verwenden, um die unzugänglichen Parameter und Zuordnungen zwischen Geräten zu konfigurieren. Das ist eine echte Schande.
p.p.s.
Offensichtlich verstehe ich kein Wort Deutsch. Ich übersetze das alles mit google.translate 
I’ll answer in English, if that helps. I’m not an expert in Homegear and I don’t know anything about the development process, so I’m not really the right person to help you.
Right now I can use both the stable and the nightly version of Homegear with my Max!-devices. I seem to be able to switch between both versions without any problem. As I don’t get any better value out of the nightly version, I use the stable one.
A few weeks ago I had the problem of the Admin UI no longer showing most of the configuration options and strange minor visual glitches (missing icons and so on). I also got permission problems when trying to change some settings. As I did nothing special with my Homegear installation besides regularly updating from the official repo I assume that there must have been subtle changes which silently messed up my configuration.
I now run a dockerized homegear and I completely started this one from scratch. The only files I reused from my old installation were /etc/homegear/families/max.conf and /var/lib/homegear/db.sql. This kept my parings intact.
(I cannot reproduce in retrospect which changes I did in the lots of other config files after the re-installation. Not many as far as I remember.)
OT: I run most of my smarthome stuff now with Zigbee (over ConBee-Stick) and Homeassistant. It is really relaxing to have a standardized, easy-to-configure and open wireless protocol instead of the proprietary MAX!-mess and, on the software side, an well-supported stable software stack with a large community.
Unfortunately, for heating there are not many options, and re-equipping my whole home with another system (including window sensors and stuff) would be rather expensive, so I’ll stick with the Homegear/Max-combination for now.
This is something completely different, if i understand correctly.
Homegear-UI is not completely configurable via the Admin-UI yet, you need to call some special functionset to make that usable. I did not use that yet, it’s just 2nd hand information.
Sorry but english is not my native language, but let’s try …
I found, that using the command’s as Patrik has named, are not working as easy as it should be.
These commands have deprecated functions, which are working fine.
# homegear -e rc 'print_v($hg->getParamset("KMD3047784:0","VALUES"));'
(Struct length=7)
{
[BOOT] (Boolean) 0
[CONFIG_PENDING] (Boolean) 0
[LOWBAT] (Boolean) 0
[RSSI_DEVICE] (Integer) 0
[RSSI_PEER] (Integer) 0
[STICKY_UNREACH] (Boolean) 0
[UNREACH] (Boolean) 0
}
# homegear -e rc 'print_v($hg->getParamset("KMD3047784:0","MASTER"));'
(Struct length=182)
{
[ENDTIME_FRIDAY_1] (Integer) 420
[ENDTIME_FRIDAY_10] (Integer) 1440
[ENDTIME_FRIDAY_11] (Integer) 1440
[ENDTIME_FRIDAY_12] (Integer) 1440
....
[TEMPERATURE_WEDNESDAY_6] (Float) 30
[TEMPERATURE_WEDNESDAY_7] (Float) 30
[TEMPERATURE_WEDNESDAY_8] (Float) 30
[TEMPERATURE_WEDNESDAY_9] (Float) 30
}
# homegear -e rc 'print_v($hg->getParamset("KMD3047784:1","VALUES"));'
(Struct length=18)
{
[ACTUAL_TEMPERATURE] (Float) 22.8
[BOOST_POSITION] (Integer) 80
[BOOST_TIME_PERIOD] (Integer) 1
[COMFORT_TEMPERATURE] (Float) 21.5
[CONTROL_MODE] (Integer) 0
[DECALCIFICATION_TIME] (Integer) 660
[DECALCIFICATION_WEEKDAY] (Integer) 0
[ECO_TEMPERATURE] (Float) 16.5
[LOCKED] (Boolean) 0
[MAX_TEMPERATURE] (Float) 30.5
[PARTY_STOP_DAY] (Integer) 1
[PARTY_STOP_MONTH] (Integer) 1
[PARTY_STOP_TIME] (Integer) 0
[PARTY_STOP_YEAR] (Integer) 12
[SET_TEMPERATURE] (Float) 17
[TEMPERATURE_OFFSET] (Integer) 7
[VALVE_STATE] (Integer) 0
[WINDOW_OPEN_TEMPERATURE] (Float) 12
}
# homegear -e rc 'print_v($hg->getParamset("KMD3047784:1","MASTER"));'
(Array length=0)
[
]
But with the non deprecated functions I got this:
# homegear -e rc 'print_v($hg->getParamset(1,0));'
(Struct length=182)
{
[ENDTIME_FRIDAY_1] (Integer) 420
[ENDTIME_FRIDAY_10] (Integer) 1440
[ENDTIME_FRIDAY_11] (Integer) 1440
[ENDTIME_FRIDAY_12] (Integer) 1440
....
[TEMPERATURE_WEDNESDAY_6] (Float) 30
[TEMPERATURE_WEDNESDAY_7] (Float) 30
[TEMPERATURE_WEDNESDAY_8] (Float) 30
[TEMPERATURE_WEDNESDAY_9] (Float) 30
}
# homegear -e rc 'print_v($hg->getParamset(1,1));'
(Array length=0)
[
]
All relevant data are missing. I looks like the deprecated function support’s “MASTER” and “VALUES” but the new function only supports master.
And of course its not possible to set “non existant” parms…
For me there is no content difference between “MASTER” and “VALUES” so far. They are just settings.
And I haven’t found a document to explain the difference. I’m frustrated for now.
Henning
I know … It was to talk about other problems of the U.I. I have added all the devices and the rooms and I have assigned the devices to the rooms and all the rest from the admin page… But then when I go to the user UI, I find the “devices”, “rooms” tabs empty and I have no way to view existing items… In reality, however, I don’t care because I then use Homeassistant to manage the heating. Homegear I use it with a CUL instead of the Max! cube that has long since broken …
Yes @Larx, I just wanted to know if you had successfully downgraded and what files I had kept to keep the configuration …
Sie können weiterhin auf Deutsch schreiben. Ich habe nur gewarnt, dass ich den Google Übersetzer verwende, damit etwas, das ich schreibe, schlecht geschrieben werden kann.
Sorry this is not related to the origin of this thread. But to answer your issue:
What you probably did is the first two steps wihin the admin-UI. The last step is only possible via command line but mandatory to visualize anything.
@Sim
Ich verstehe nicht, was die Zuordnung von Variablen zu Räumen und Rollen für die UI, mit dem Problem der Nicht-Konfigurierbarkeit der Thermostate in der 'Admin-UI zu tun hat…
@Larx
Ich habe heute die stable 0.7.48 mit Raspian Buster auf einem pi 4 neu installiert.
Dann habe ich ein Gebäude, 3 Stockwerke und einen Raum eingerichtet,
den CUNX-CUBe als Gateway.
Schließlich habe ich noch ein Basic Thermostat mit dem CUBe gepairt.
Ergebnis:
Die Werte wie z.B. TEMPERATURE_OFFSET lassen sich auch in dieser Version in der Admin-UI nicht konfigurieren…
Damit bleiben nur 2 Möglichkeiten, warum es bei dir funktioniert.
Entweder stehen in deinen Konfigurationsdaten Werte, die ein abweichendes Verhalten verursachen, oder das von dir verwendete Docker-Image macht irgendetwas anders.
Beides Dinge die sich meiner Meinung nach ein Entwickler ansehen müsste…
Kann ich leider nix zu sagen. Da ich Homegear auch nur benutze, um Max-Thermostate ansteuern zu können, und mit Stockwerken usw. gar nichts rumkonfiguriere, bin ich zufrieden, dieses Ziel wieder erreicht zu haben ;-).
Yes, thank you, I know this answer, I received it in my previous post/thread… Not easily understandable… Not for all configure using command line (I could do it but i wan’t do… The system should also be configurable by my son or my wife).
What I’d really like to be able to do from the U.I. admin is to configure the missing parameters (as reported in the thread) and the pairing from the devices; in this way I could avoid using Homematic Manager … But that’s okay in the end …
You can configure everything that is missing using Homematic Manager …
Happy New Year to all of you dear home automation friends, I hope 2021 is better and this suffering for Covid-19 ends
I guess the Homegear philosophy is not to make everything configurable for everyone, unfortunately. It’s aim seems to be to provide an API for programmers, UI are not really the priority.
So for me it’s just a kludge to get Max working and integrated in something better accessible for the rest of the household (including myself). Fortunately, once the Max stuff is set up, you don’t really have to go into the details any more too often. (Max in itself isn’t too reliable, unfortunately.)
Concerning Homematic Manager - when I was in the situation that the admin ui of Homegear did no longer offer most of the configuration options, they were also missing in Homematic Manager…
I guess, your guess is wrong. I guess it’s simply a matter of “too much to do, not enough time”. Nothing to to do with philosophy or strategy.
Is already known if the problem of the missing config parameters is a matter of the AdminUI or the Api-Call to find them?
As far as I understood, the problem is, that the missing data are defined als “values” in MAX! devices, not as “parms”.
But I get no answer what is the reason for the difference in device definitions comparable to homematic devices yet.
And thus a end-user cannot say where the problem is …
You need to ask eq-3 this question. They designed this structures.
According to my opinion, a workaround needs to be applied. If in Homegear or the AdminUI needs to be decided. Also the size of the workaround. Is it needed only for some devices or the whole family?
But with Max! being just one family among many, and also one being end of life already this might not be on the top of the list.
That’s a really important information here. Since we, the end-user did not know anything about the internals.
I’m not an expert. But I have checked all heating devices and the wall thermostat. These definitons all have the structure, same problem. So I guess it’s a family problem.
And maybe in future other families may have similar problems. If i understood my former work colleagues (java devs) correctly, it should be easy to transform one XML to another. If necessary it can done by hand.
So my idea to solve the problem for all families and all devices is to add an optional additional layer (like a view in a database ). If this layer was found, then it is used. If not the original device definiton is used.