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.
I believe that a home automation product should have every parameter configurable from a graphical user interface; in the end it is not a programmer who may have to fix things but an electrician who is installing the valves of a radiator … Furthermore, even the end user should be able to configure things after all. I am a professional programmer with a m.o.s. in computer science and I also have a diploma in electronics so I have no problem doing anything but I would really like to write an instruction manual for the configuration of my house to give to my wife or my son … I could also be in hospital or die and they wouldn’t know how to make anything work … About Homematic Manager, with it I was able to configure everything, there is nothing that is not included; I also made a fork which is on my github page with a couple of bugs fixed and the full English translation. About MAX !, it is true, the product is at the end of its life cycle but the peripheral devices are not so bad, only the cube had to be replaced and I made a CUL for that … Honestly I tried to look at the code of homegear to try to fix the problem myself but I couldn’t “put the pieces together” of the user interface so I didn’t really understand where to put my hands … The work seems too expensive in time and I’m trying to understand how to integrate all the programming directly into Homeassistant using only the homegear API (during holidays 
) …
That’s all
@arkimede
I found that it’ possible to show (and change) a value of channel 1 parms in the Admin-UI, if I modify device definitions for BC-RT-TRX-CyN. But I have no idea what other effects this change will have.
Since I’m not running homematic, home-assistant or OpenHAB for now I can’t check.
Do you have BC-RT-TRX-CyN or BC-RT-TRX-CyG devices? Then I can try to build more complete modification for one of them. If you are willing to do some tests, this would be great…
Btw. I’m using a modified -credit free- firmware on my CUBe’s for testing purposes. I don’t understand anyway, why it should be better to use 100 cubes with each 1% limit then only 1 cube with no restrictions …
Henning
@fow0ryl Very interesting!.. Btw, where did you find such firmware?!? Does it keep the original function or does it become a CUL? I have that one… Also can you provide the change in the device definition?
@arkimede
I initaly find a hint to a-culfw nocredits firmware here and started flashing my CUBe’s with the provided version. But fiddeling with a terminal to write new a-culfw versions was laborious.
Then I found this german blog where I was pointed to “Neuer Bootloader”.
So I changed the bootloader again to the newest version from here, but still using the firmware provided in the home-assistant forum.
I asked where to get other firmware versions but got no answer.
Then I found some sources at github mattwires culfw.
With this knowledge it should be easy to modify the actual version provided by heliflieger for every supported device.
Credit’s from 1% to 100% sould be possible too.
