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?
2 Likes
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.
2 Likes
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.
@fow0ryl
Ok, thanks, i know that firmware. I thought you had found one that maintained full compatibility with the MAX system… I created an interface with a CC1101 connected directly to the Raspberry4 that works as a Homeassistant server; the power of the Rasp4 microprocessor is enough to run Homeassistant, Homegear and even Motion where I have connected some surveillance cameras. Previously I was using a Rasp3 with a CUL (Arduino board + CC1101) connected to the USB port. Interesting the change to the definition of the device, can you tell me what you have changed? I immediately try to implement …
For now I have only changed the device definition. In the log I found that changing a value is executed.
Since I haven’t made anything with smart home until last chrismas, I dont know if the changes really changes the values on the devices. Never used node-red or node-blue yet.
Do you have node-blue flows to set & request the values directly from a device?
Can you provide them?
I simply moved some definitions in the xml file from variables to parms. And thus they are displayed…BC-RT-TRX-CyN.xml (134,2 KB)
Since XML is text based you can make a simple diff to show the changes.
thanks will see it right away…
Sorry, not used node blue/red
Hello everyone,
as stated before, the issue is known. But due to the lack of the affected device I’m not able to reproduce the issue. The code is the same for all other devices, so I’m stuck here 
And yes, we’re absolutely interested in your feedback and trying to integrate new features as fast as possible. Unfortunately time is short …
– Micha
1 Like
Hi all,
finally found the problem, thank you to @fow0ryl
It’s sufficient to add the missing definition for channel 2
<function channel="2" type="NOT_USED" channelCount="0">
<properties>
<linkReceiverFunctionTypes>
<type>NONE</type>
</linkReceiverFunctionTypes>
</properties>
</function>
no other modifications required to the xml definition file.
The bug appears to be into the device definition file parser …
Now I try to edit other device definitions…
1 Like
For wall thermostat BC-TC-C-WM-4 added two unused channels and it works
<function channel="2" type="NOT_USED" channelCount="0">
<properties>
<linkReceiverFunctionTypes>
<type>NONE</type>
</linkReceiverFunctionTypes>
</properties>
</function>
<function channel="3" type="NOT_USED" channelCount="0">
<properties>
<linkReceiverFunctionTypes>
<type>NONE</type>
</linkReceiverFunctionTypes>
</properties>
</function>
… 
1 Like
Could you do a pull-request for GitHub - Homegear/Homegear-MAX: MAX! module for Homegear?
The device description files are part of the package.
Ok, at this point a deep breath …
I did other tests, currently I have the nightly build 3169 version, the variables of channel 1 appear regularly in the configuration page without any changes in the definition files.
At this point the only “error” I see is the presence of channel 2 in the configuration parameters page, but it is empty so I would say it is not a problem …
I can’t say more now … Can you check?
1 Like