Initial contribution of the Homematic binding #438
Conversation
kaikreuzer
added
the
new binding
|
Wow, this is a lot of code :-) I hope I will try to review it in November. |
|
Yes, it grew bigger and bigger :-) |
|
alright, thanks for the infos! |
|
Hi, I've compiled a current snapshot of openhab/openhab2 and integrated the homematic2 binding from gerrieg/openhab2 homematic branch. HomeMatic device discovery works fine (I am using homegear), but if I want to save a thing, I get a 500 error. More curiously, I cannot create any more groups after that so I assume, the mapdb gets somehow corrupted. I have not (yet) the necessary insight into the codebase, so could you therefore look into the problemto find out if this is a real bug or just me? @gerrieg 2015-11-08 00:24:48 [WARN ] [lipse.jetty.server.HttpChannel:395 ] - /rest/inbox/homematic:HG-HM-LC-Dim1TPBU-FM:a0d0f3e3:JEQ0XXXXXX/approvejavax.servlet.ServletException: javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.io.IOError: java.nio.channels.ClosedChannelException |
|
Maybe your mapdb files are corrupt. Delete the three files in your openhab_home folder (userdata/mapdb) and try it again please. |
|
I always tried with a fresh installation, wether I compiled the current master and integrated the HomeMatic binding or I compiled your branch. Therefore deleting the userdata folder would probably be only effective as long as I would not add another HomeMatic thing ;-) PS: Thanks for getting back to me so quickly. I have worked all weekend on my openHAB2 HM2-binding setup and your work ist just great! 👍 |
|
I also think that this is a paperUI issue. Just tried it with a fresh installation and a homegear installation with 30 devices. Can't reproduce the exception. |
| <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> | ||
| <classpathentry excluding="org/openhab/binding/homematic/internal/bridge/binrpc/" kind="src" path="src/main/java"/> | ||
| <classpathentry kind="src" path="src/main/resources"/> | ||
| <classpathentry kind="src" path="src/test/java"/> |
There was a problem hiding this comment.
please remove the two test entries as these paths do not exist.
I know, but I commented that above already with: "ok to refresh all channels of a thing if a REFRESH is received for any of its channels)" I guess this is what you will in any case do, right?
No, there is no need to do this! Your handler can simply dynamically set properties on the thing, e.g. in the initialize() method (or whenever you are able to read the firmware version and other static properties). |
|
Hi Kai! I've implemented now Thing parameters, system channels, the refresh command, channel groups and prepared channel and parameter descriptions. What i want to add now is Homematic IP support for the new CCU firmware. The required XML-RPC communication is already done (not yet commited). I've ordered a HM-IP device and will then implement the rest. BR, Gerhard |
|
Sounds like a productive long Easter weekend, cool 👍 |
|
Yes, one day family, two days openHab 😄 OK, sounds good. So give me two more days for some tests and to update the readme.md file. I have one problem, but i think it's a PaperUI issue. If i open the Thing parameters, all decimal type parameters are not shown. Metadata with the rest-api looks good for me. So i don't know if its my fault or that of PaperUI. |
I just tested this by changing this line from integer to decimal and it all works nicely in the Paper UI. If you can find a way to reproduce your problem with the Yahoo Weather binding, please enter an issue at https://github.com/eclipse/smarthome/issues |
|
So here is my Homematic contribution for OH2. With the Thing parameters i need your help, i'm out of ideas what i can do. PaperUI still does not show decimal type parameters. Maybe you can try the binding and give me a hint? |
kaikreuzer
removed
the
awaiting feedback
|
Thanks! I will try to look at the problem soon. (Please allow me a few days as I am currently on holiday) |
|
As I do not have my CCU2 with me on holidays - can you give me a hint on how I can reproduce your problem with the decimal properties? Adding a Homematic thing manually is only possible for the gateway, but this does not have any decimal properties. No other thing types are offered (since they are only created once the gateway connection is established). |
|
If you're familar with docker and homegear, you can add a virtual homegear device at homegear. Maybe event the presence of homegear (>= 0.6) us sufficient. |
|
enjoy your holidays and relax! 😎 🌴 🍹 |
|
Ok, just returned back home and connected to my CCU2. What worries me more though is the fact that the config properties and channels that I see do not really match my expectations for a user friendly solution - the automatic creation of the thing types might be at its limits here. Let me give you an example: I have a HM-CC-SCD. I don't really know how do address these things best, considering the fully automatic creation. But imho we should at least try to hide most configuration parameters as well as channels by marking them as "advanced". The names of the channel groups must definitely be changed as well. |
kaikreuzer
added
the
awaiting feedback
|
Exceptions and problems: Metadata: Config and Channel descriptions: Advanced: |
It does not make sense to me because "Homematic channel" and "Thing channel" get mixed up here. "Homematic Channel 0" is then a Thing channel group with x "Thing channels".
Ok, cool, makes sense!
Yes, that's the idea of the "advanced" flag. A regular user should not be flooded with options that he hardly ever needs to be aware of.
Yes, at least for a start. On the long run, it might make sense to have some optional property file within the binding that could hold this information for different names (and maybe also a label to be used, as mentioned above "STATE" is a terribly generic and technical name for the label of the most important channel.
So a separate property file could help here as well - I would actually also suggest that it should be possible to completely ignore certain channels/parameters. Take e.g. the wall thermostat: I saw a mass of configuration properties about the scheduling thresholds, which made the configuration screen almost unusable as you had to scroll over many many pages and couldn't find anything anymore. |
|
Hi @gerrieg! |
|
Hi @kaikreuzer ! Yes, the descriptions are already done. I found a way to extract the most descriptions directly from the CCU (see CcuMetadataExtractor). They are spread around many JavaScript files and are concatenated partly. So the most can be extracted and the missing ones can be added in the extra-descriptions.property file over time. ChannelGroup shows the type now. I am still working on the advanced flag. I have a concept now and i'm going to implement it in the next days. |
|
Sounds great, many thanks! |
|
Hi @kaikreuzer! I identified the standard datapoints for the most devices and marked all others with the advanced flag. I'm sure, this must be optimized for devices i don't own like a heating thermostat. But that can be done easily in the standard-datapoints.properties file. Descriptions are available for the most datapoints now, some are extracted from the CCU, some are added manually. There are still missing descriptions which should be added over time. At device discovery, missing descriptions are logged. Homematic IP support is also included now (via CCU2) I switched the execution environment to JavaSE-1.8, but this is only for the Base64 class included in this jdk. Or is it better to user JavaSE-1.7 and the Base64 class from commons-codec? |
|
Thanks a lot, that sounds great! |
kaikreuzer
removed
the
awaiting feedback
| org.osgi.framework, | ||
| org.osgi.service.component, | ||
| org.slf4j | ||
| Service-Component: OSGI-INF/* |
There was a problem hiding this comment.
please change this to OSGI-INF/*.xml
Signed-off-by: Gerhard Riegler <gerhard.riegler@gmail.com>
|
done and squashed all commits |
|
Thanks again! |
Signed-off-by: Gerhard Riegler <gerhard.riegler@gmail.com>
Documentation
Open issue: