Homematic Binding: code for review... Implementation of Error (Sabotage), Unreach and LowBat datapoints

[Lars K]

Hi everyone.

I have spend some time to improve the homematic binding a little bit. As I was missing the possibility to create items that are bind to the ERROR datapoint. Sensor like the HM-Sec-RHS (Rotary handle sensor) do use this datapoint to report physical manipulation (sabotage).

There are to ways to bind such an item:

Switch Sabotage_EG_Wohnzimmer_Terrasse "Sabotage Terrasse [MAP(de.map):Sabotage_%s]" <siren> (Sabotage) {homematic="JEQ0123456:1#ERROR"}

OR

Number Sabotage_EG_Wohnzimmer_Terrasse "Sabotage Terrasse [MAP(de.map):Sabotage_%s]" <siren> (Sabotage) {homematic="JEQ0123456:1#ERROR"}

The first kind is just OFF if the device delivers a 0 on ERROR and ON if the value is higher than 0.

The second is delivering the real value from the ERROR datapoint. My rotary handle sensor is reporting a 7 as sabotage.

Unreach messages are bound like this:

Switch Unreach_EG_Wohnzimmer_Terrasse "Kommunikationsstörung Terrassentür [%s]" <siren> (Unreach) {homematic="JEQ0123456:0#UNREACH"} 

Lowbat the same way:

Switch Lowbat_EG_Wohnzimmer_Terrasse "Leere Batterie Terrassentür [%s]" <siren> (Unreach) {homematic="JEQ0123456:0#LOWBAT"} 

The code changes can be found in my repo clone:

https://code.google.com/r/lkuech-openhab/

I hope I did everything right :)

Best regards from Hamburg

Lars

[Kai Kreuzer]

Hi Thomas (L.),

Could you take care of this review?

Just let me know, which changesets to pull, if things are done!

@Lars: Thanks for this contribution, this is definitely something that was missing in the HM binding!

Cheers,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Letsch]

Hi,

@Lars:

Thanks for your contribution! I could already review it and its quite ok. 

One thing is missing: Please provide also an unit test for each new key (or device - in this case one device as example should be ok) in the homematic test package. Have a look at org.openhab.binding.homematic.internal.bus.TemperatureSensorTest for an example for read-only values.

Still have to figure out which is now the correct way to include this patch :-)

R.,

Thomas

[Lars K]

Hi Thomas.

As there is currently not much documentation inside the code, can you explain me a bit more about this test project and how it is been used? I hate putting code in something I'm not able to use or test my self. I prefer to test my changes before I commit them.

I guess the ERROR datapoint should be there on all *SEC* devices. The UNREACH should be present on all devices. LOWBAT should be present on all Battery driven devices.

[Thomas Letsch]

Hi Lars,

yeah, sure. I probably should document that better...

First, the test project is just a container for the unit test classes. I just copied this separation from the other bindings. My assumption is that its because of OSGI that we must separate the testing code from the production code. Perhaps its because you need to create a test binding to use OSGI functionality with the chance to deploy only the production code to a working system. The homematic binding does not use OSGI functionality, but I just followed this pattern. And I do not know if tycho (the OSGI Maven Plugin) does obey the maven file structure when creating the bundle.

The unit tests can be executed like any other unit tests from within eclipse of through maven from the command line (which is done in the Jenkins build). 

The idea behind these tests is to ensure that the data processing inside the binding works correctly. It tests the conversion of the HM value to the OH values and vice versa. Another important thing is to document the expected behavior of the homematic binding, especially what should be mapped for which class of devices. Since your additions are mainly very generic ones, there is of course no test class per device but per parameter.

The tests itself get a basic configured binding from the BasicBindingTest and can use some utility methods that makes testing quite easy. I will javadoc these methods.

Does that answer your questions?

R.,

Thomas

[Lars K]

Am Sonntag, 5. Mai 2013 19:33:10 UTC+2 schrieb Thomas Letsch:

Does that answer your questions?

R.,

Thomas

Well... I hope ;)

I've created 4 new test classes.

UnreachTest.java  (test class for the Unreach datapoint)

LowBatTest.java  (test class for the LowBat datapoint)

SabotageSwitchTest (test class for the ERROR datapoint using the new converter class >0 == True)

SabotageDecimalTest  (test class for the ERROR datapoint receiving by int)

Is this what you had in mind?

If so, I can commit these classes to my repo clone so you can check and maybe merge them.

[Lars K]

I've committed the 4 classes to my repo clone. So you can review them.

If I understand it right, as soon as you have validated the addition, Kai will merge them into the official repo.

 

Best regards

Lars

[Thomas Letsch]

Hi Lars,

thanks, that was it. Now if you switch the names of SabotageSwitchTest and SabotageDecimalTest everything can be integrated :-)

R., Thomas

[Lars K]

Ok.

But, switch to what?

[Thomas Letsch]

well, I suppose SabotageSwitchTest should be named SabotageDecimalTest and SabotageDecimalTest should be named SabotageSwitchTest :-)

[Lars K]

:D

Upps. Not sure how that one happens ;)

Now it should be fine.

[Thomas Eichstädt-Engelen]

Hi Lars, Thomas,

thanks for contributing and reviewing this issue. Added your changesets to the default branch recently. They will be available in build #405

Regards,

Thomas E.-E.

[Kai]

Thomas L, Lars,

I just noticed that his feature has never made it to the Homematic binding wiki page - could you add the according documentation?

Cheers,

Kai

[Lars K]

I will have a look this evening.

[Lars K]

Done :)

[Kai Kreuzer]

Thanks!

And one very last wish: Could you rename your examples from German ("Kommunikationsstörung Terrassentür") to English? :-)

Cheers,

Kai

Visit this group at http://groups.google.com/group/openhab.

[Lars K]

No problem. 

Done as well.

regards

Lars