Implementation of MAX! CUL Binding

[Paul Hampson]

I have just started work on a binding that uses the CUL transport to interact with eq-3 MAX! devices. 

Work is being done here: https://github.com/cyclingengineer/openhab/tree/maxcul-binding and I have created and issue to track this here: https://github.com/openhab/openhab/issues/1085

Currently I have written binding configuration code and some bits that will be required for pairing mode. If you want more details then please ask.

I'll try and remember to update this thread as and when I have things completed and ready for testing so I can get feedback.

Thanks,

Paul

[Paul Hampson]

Update for anyone interested:

Please read the beginnings of documentation that are available on the wiki. It describes the current functionality and limitations. - https://github.com/openhab/openhab/wiki/MAX!-CUL-Binding

Initial pull request is here - https://github.com/openhab/openhab/pull/1200

It looks like my binding is causing no problems build wise. 'Unstable' build result seems to be down to some other tests failing (not a regression on my part).

Snapshot JARs are available from cloudbees. E.g. https://buildhive.cloudbees.com/job/openhab/job/openhab/838/org.openhab.binding$org.openhab.binding.maxcul/artifact/org.openhab.binding/org.openhab.binding.maxcul/1.6.0-SNAPSHOT/org.openhab.binding.maxcul-1.6.0-SNAPSHOT.jar

Thanks,

Paul

[Kai Kreuzer]

Hi Paul,

This is really cool, thanks for this contribution!

It looks like my binding is causing no problems build wise. 'Unstable' build result seems to be down to some other tests failing (not a regression on my part).

Yes, you are right, there were some problems with tests on Buildhive, so you can safely ignore those messages :-)

Best regards,

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.
For more options, visit https://groups.google.com/d/optout.

[bste...@gmail.com]

Hi Paul,

i would like to test your binding, but when i download the snapshot from cb your package is not included.. :( ..when i download it from modules it is not starting up! (i have the settings in my openhab.cfg, but when i start in debug mode there is no error or any message from your binding..)

can you give me a little push in the right direction to get it working?

thanks you for your help!

  Bernhard

[Paul Hampson]

Hi Bernhard,

I'd be interested to have someone else test this and come along for the ride - I can't promise its a polished binding - so be prepared, but I am using at home at the moment with autumn well and truly here and winter just round the corner and it seems to be holding up okay for the way I use it :-)

The snapshot issue is a bit weird. It has been built but isn't in the zip file. I suspect something is missing in a file somewhere to tell it to put it in the zip file. In any case the latest one can be found here - https://openhab.ci.cloudbees.com/job/openHAB/org.openhab.binding$org.openhab.binding.maxcul/

You will also need the cul transport io plugin from here - https://openhab.ci.cloudbees.com/job/openHAB/org.openhab.io$org.openhab.io.transport.cul/

The lack of transport plugin is probably why you get no output as the binding won't start without it.

Hopefully we can work through any more issues you come across :-)

Thanks,

Paul

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/T61K_PRC9o8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Bernhard Steinert]

Hi Paul,

thank you for you quick response, i found out this dependency just yesterday morning.. ;-) ..would it be a good idea to log an error if someone put your binding in the addons folder but forgot the transport?

i played a round a little bit, the listenmode ist amazing! :-D ..i'm a little shocked that the protocol is so open and unsecure.. :(

i have started migrating my first thermostat from maxcube to maxcul, but something seems to to went wrong.

i have paired it with openhab, now i see the messages from that device coming in:

08:55:38.106 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0C1A04420DB81000A023002AD518

08:55:38.148 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0E1A020200A0230DB810000138052A03

08:57:11.971 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0F00046000FB460000000019002100D3FB

08:57:11.978 DEBUG o.o.b.m.internal.MaxCulBinding[:307]- Received data from CUL: Z0F00046000FB460000000019002100D3FB

08:57:11.984 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:45]- THERMOSTAT_STATE Payload Len -> 5

08:57:11.990 DEBUG o.o.b.m.i.messages.BaseMsg[:374]- Raw Message: Z0F00046000FB460000000019002100D3FB

08:57:11.993 DEBUG o.o.b.m.i.messages.BaseMsg[:375]- Length    => 15

08:57:11.997 DEBUG o.o.b.m.i.messages.BaseMsg[:377]- Msg Count => 0x0

08:57:11.999 DEBUG o.o.b.m.i.messages.BaseMsg[:379]- Msg Flag  => 0x4

08:57:12.003 DEBUG o.o.b.m.i.messages.BaseMsg[:381]- Msg Type  => THERMOSTAT_STATE

08:57:12.005 DEBUG o.o.b.m.i.messages.BaseMsg[:382]- Src Addr  => 00FB46

08:57:12.009 DEBUG o.o.b.m.i.messages.BaseMsg[:383]- Dst Addr  => 000000

08:57:12.012 DEBUG o.o.b.m.i.messages.BaseMsg[:384]- Group ID  => 0

08:57:12.015 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:97]- Desired Temperature => 16.5

08:57:12.018 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:98]- Measured Temperature=> 21.1

08:57:12.021 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:99]- Valve Position      => 0

08:57:12.024 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:100]- Control Mode        => MANUAL

08:57:12.027 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:101]- DST Active          => true

08:57:12.029 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:102]- LAN Gateway         => true

08:57:12.032 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:103]- Panel locked        => false

08:57:12.034 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:104]- RF Error            => false

08:57:12.037 DEBUG o.o.b.m.i.m.ThermostatStateMsg[:105]- Battery Low         => false

08:58:28.100 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0C1B04420DB8100BC306002AD517

08:58:28.144 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0E1B02020BC3060DB810000118002A21

09:01:14.597 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0C1C04420DB81000A023002AD515

09:01:14.642 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0E1C020200A0230DB810000138052A09

09:04:13.344 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0C1D04420DB8100BC306002AD515

09:04:13.389 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356]- MaxCulSender Received Z0E1D02020BC3060DB810000118002A27

..but the items i defined don't get updated..

here my config for the items:

Number  Max_Kueche "Thermostat Kueche [%.1f °C]" <heating> (gKueche) { maxcul="RadiatorThermostat:IEQ0184944" }

Number  Max_Ventil_Kueche "Ventil Kueche [%.1f %%]" <heating> (gKueche,gVentil) { maxcul="RadiatorThermostat:IEQ0184944:feature=valvepos" }

String  Max_Batterie_Kueche "Batterie [%s]" <heating> (gKueche) { maxcul="RadiatorThermostat:IEQ0184944:feature=battery" }

i don't know if it's the right way, i think it should work and i have done everything like it is in your documentation...

do you see any thing i've done wrong?

thanks you very much for your help,

Bernhard

[Bernhard Steinert]

Hi Paul,

sorry for the inconvience, i found out that i cannot pair the thermostat with openhab. i have invoked the pairmode, but it not seems to pair any way...

kind regards

Bernhard

[Paul Hampson]

I suspected that is what happened. You will need to factory reset the thermostat (see the manual of how to do that. If I remember correctly you need to hold all three buttons and then insert the batteries)  before pairing otherwise it just tries to pair again with the cube (i.e you will see a non-broadcast PAIR_PING message)

Hope that helps
Paul

[CeePo]

may I chime  in here?
I am having problems to get cul and devices together... hardware is a raspberry pi, a cul usb dongle and max radiator thermostat. maxcul binding and io.cul transport are in the correct places. so I run start_debug.sh:

16:49:25.433 DEBUG o.o.b.m.i.MaxCulActivator[:34] - MaxCul binding has been started.
16:49:25.947 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'listen (Type=SwitchItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
16:49:26.001 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item listen
16:49:26.164 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:41] - Listen Mode switch found
16:49:26.207 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'pair (Type=SwitchItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
16:49:26.233 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item pair
16:49:26.252 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:37] - Pair Mode switch found
16:49:26.273 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'RadTherm1 (Type=NumberItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
16:49:26.300 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item RadTherm1
16:49:26.316 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:52] - Found real device
16:49:26.322 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:54] - Part 0/2 -> RadiatorThermostat
16:49:26.333 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:59] - Part 1/2 -> KEQ1017129
16:49:26.345 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:67] - Part 2/2 -> feature=temperature
16:49:26.366 WARN  o.o.b.m.i.MaxCulBindingConfig[:131] - Unable to locate information for RADIATOR_THERMOSTAT KEQ1017129 it may not yet be paired

ok, let's pair...
and I turn on the pair switch and press the boost button of the thermostat, but ....


16:55:58.712 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:62] - Received raw message from CUL: z
16:55:58.726 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356] - MaxCulSender Received z
16:56:03.699 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:62] - Received raw message from CUL: 4V�KEQ1017129z

.... and no pairing whatsoever.
any clues? I have been successful in getting this combination of cul and thermostat to work in FHEM, but I'd rather use openhab.
thank you.
ceepo

[Paul Hampson]

Hi Ceepo,

Those strings we are receiving from the CUL are weird. They don't seem to make sense. Have you got any weird modes set from FHEM use?

Could you add the following to logback.xml and then send me the full log from a normal start up and then pairing attempt:

<appender name="MAXCULFILE" class="ch.qos.logback.core.rolling.RollingFileApp   <file>logs/maxcul.log</file>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">      <!-- weekly rollover and archiving -->
      <fileNamePattern>logs/maxcul-%d{yyyy-ww}.log.zip</fileNamePattern>
      <!-- keep 30 days' worth of history -->
      <maxHistory>30</maxHistory>
   </rollingPolicy>
   <encoder>
     <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{30}[:%line]- %msg%   </encoder>
</appender>

<logger name="org.openhab.binding.maxcul" level="DEBUG" additivity="false">

This will put all maxcul output (except exceptions) into maxcul.log and you won't need to start in debug mode.

Thanks
Paul

--

[CeePo]

Hi Paul,
thanks a lot. First of all, I've added this to logback.xml:

<appender name="MAXCULFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${openhab.logdir:-logs}/maxcul.log</file>

        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">     
            <!-- weekly rollover and archiving -->

            <fileNamePattern>${openhab.logdir:-logs}/maxcul-%d{yyyy-ww}.log.zip</fileNamePattern>

            <!-- keep 30 days' worth of history -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>

            <pattern>%d{yyyy-MM-dd HH:mm:ss} - %msg%n</pattern>
        </encoder>
    </appender>
 
    <logger name="org.openhab.binding.maxcul" level="DEBUG" additivity="false"/>

A file maxcul.log is created in /logs but no logging happens, file size zero. So in the meantime, here is what I get when I start openhab in debug mode (only Max related lines):

12:00:41.959 DEBUG o.o.b.m.i.MaxCulActivator[:34] - MaxCul binding has been started.
12:00:42.479 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item listen
...
12:00:42.553 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:41] - Listen Mode switch found
12:00:42.582 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'pair (Type=SwitchItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
12:00:42.587 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item pair
12:00:42.597 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:37] - Pair Mode switch found
12:00:42.617 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'RadTherm1 (Type=NumberItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
12:00:42.628 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item RadTherm1
12:00:42.647 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:52] - Found real device
12:00:42.656 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:54] - Part 0/2 -> RadiatorThermostat
12:00:42.662 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:59] - Part 1/2 -> KEQ1017129
12:00:42.677 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:67] - Part 2/2 -> feature=temperature
12:00:42.686 WARN  o.o.b.m.i.MaxCulBindingConfig[:131] - Unable to locate information for RADIATOR_THERMOSTAT KEQ1017129 it may not yet be paired
12:00:42.707 DEBUG o.o.m.i.i.GenericItemProvider[:334] - Start processing binding configuration of Item 'RadThermBatt (Type=NumberItem, State=Uninitialized)' with 'MaxCulGenericBindingProvider' reader.
12:00:42.712 DEBUG o.o.b.m.i.MaxCulGenericBindingProvider[:101] - Processing item RadThermBatt
12:00:42.716 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:52] - Found real device
12:00:42.727 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:54] - Part 0/2 -> RadiatorThermostat
12:00:42.736 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:59] - Part 1/2 -> KEQ1017129
12:00:42.741 DEBUG o.o.b.m.i.MaxCulBindingConfigParser[:67] - Part 2/2 -> feature=battery
12:00:42.758 WARN  o.o.b.m.i.MaxCulBindingConfig[:131] - Unable to locate information for RADIATOR_THERMOSTAT KEQ1017129 it may not yet be paired
12:00:42.818 DEBUG o.o.i.t.cul.CULActivator[:35] - CUL transport has been started.
12:00:43.110 DEBUG o.o.i.transport.cul.CULManager[:110] - Registering class org.openhab.io.transport.cul.internal.CULSerialHandlerImpl for device type serial
12:00:43.125 DEBUG o.o.i.transport.cul.CULManager[:110] - Registering class org.openhab.io.transport.cul.internal.CULNetworkHandlerImpl for device type network
...
12:00:43.273 DEBUG o.o.b.m.internal.MaxCulBinding[:100] - Activating MaxCul binding
12:00:43.288 DEBUG o.o.b.m.internal.MaxCulBinding[:228] - MaxCUL Reading config
12:00:43.293 DEBUG o.o.b.m.internal.MaxCulBinding[:244] - Setting up device serial:/dev/ttyACM0
12:00:43.322 DEBUG o.o.b.m.internal.MaxCulBinding[:263] - Opening CUL device on serial:/dev/ttyACM0
12:00:43.346 DEBUG o.o.i.transport.cul.CULManager[:52] - Trying to open device serial:/dev/ttyACM0 in mode MAX
12:00:43.357 DEBUG o.o.i.transport.cul.CULManager[:117] - Searching class for device type serial
12:00:43.352 DEBUG o.o.b.h.internal.HttpActivator[:34] - HTTP binding has been started.
12:00:43.501 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:98] - Opening serial CUL connection for /dev/ttyACM0
12:00:43.676 INFO  o.o.c.s.AbstractActiveService[:169] - HTTP Refresh Service has been started
12:00:44.003 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:117] - Adding serial port event listener
12:00:44.027 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:81] - Sending raw message to CUL: X10

12:00:44.059 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:81] - Sending raw message to CUL: Zr

12:00:44.102 DEBUG o.o.b.c.internal.CupsActivator[:31] - Cups binding has been started.
12:00:44.218 DEBUG o.o.b.m.i.MaxCulMsgHandler[:258] - Associated MaxCulBindingMessageProcessor

Ok, then I switch pair mode ON, press the Boost button on the radiator:

12:05:29.736 DEBUG o.o.b.m.internal.MaxCulBinding[:126] - Received command ON for item pair
12:05:29.742 DEBUG o.o.b.m.internal.MaxCulBinding[:129] - Found config for pair
12:05:29.760 DEBUG o.o.b.m.internal.MaxCulBinding[:158] - pair pairMode enabled & timeout scheduled
12:05:29.832 INFO  runtime.busevents[:22] - pair received command ON
...
12:05:41.519 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:62] - Received raw message from CUL: z� ���/      (z$ �x��     )z� ڌ�C     .z
12:05:41.539 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356] - MaxCulSender Received z� ���/    (z$ �x��     )z� ڌ�C     .z
12:05:46.519 DEBUG o.o.i.t.c.i.CULSerialHandlerImpl[:62] - Received raw message from CUL: �KEQ1017129z
12:05:46.525 DEBUG o.o.b.m.i.MaxCulMsgHandler[:356] - MaxCulSender Received �KEQ1017129z

This all is after I have removed FHEM from the Raspberry and after a re-flashing/resetting of the CUL dongle. Maybe the dongle is kaputt?

cheers,
CeePo

[Paul Hampson]

That serial message it gets is really very strange! You shouldn't see things like the plain texg serial number of the device in the string. It should just be a hex string preceded by a Z.

I use one of these-- http://busware.de/tiki-index.php?page=CUL I assume you use the same?

Its almost as if something is parsing the hex before it comes out of the serial port which is strange. But there is a lot of junk in there too...

Can you connect via minicom or something and paste the raw output of the serial port? It looks a bit more fundamental than the binding.

Also can you confirm what baud (bit rate) you expect your cul device to run at? Default is 9600.

Thanks.
Paul

[CeePo]

Right, it's a V 3.4 CUL.
I have little tool named cutecom to monitor the CUL. the dongle is at dev/ttyACM0, baudrate is 9600.
I send V and VH and get the version strings you see below. then I send Zr, initiate the pairing sequence on the thermostat, I get the long lines. the short line seems to come periodically from CUL.

V 1.61 CUL868
CUL_V3
Z170004000D1D14000000001001A04B455131303137313239
Z170004000D1D14000000001001A04B455131303137313239
Z170004000D1D14000000001001A04B455131303137313239
Z170004000D1D14000000001001A04B455131303137313239
Z170004000D1D14000000001001A04B455131303137313239
Z170004000D1D14000000001001A04B455131303137313239
Z0E75020205DF5D05FA2F0001080828

which looks ok I guess.
but when I send X10, things get messy like this:

z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129z\0x17\0x00\0x04\0x00
\0x1d\0x14\0x00\0x00\0x00\0x00\0x10\0x01\0xa0KEQ1017129

hope that helps in solving the mystery...
cheers
CeePo

[Bernhard Steinert]

Hi Paul,

i also have 1.61 on my CUL, and it is now working without touble. I have migrated the first thermostat and its working fine. Thank you for pointing me on the reset, thats solved it for me! :)

kind regards

Bernhard

2014-11-18 11:06 GMT+01:00 Paul Hampson <paulnh...@gmail.com>:

Ah ha! You have a newer FW version of the stick.

[Paul Hampson]

Ah ha. You have a newer version of the firmware. I have 1.58 I believe.

Maybe there is a bug in the culfw that means that the X10 command was not properly implemented and it has since been fixed. I'll have to remove this command from the transport initialisation to stop it putting it into what appears to be raw binary mode or simply change the binding to actually accept raw binary data - which might be more sensible.

In any case it's unlikely I'll have time to make the above change until next week - so as a work around it might be worth downgrading your CUL to v1.58 and trying that to get started?

Thanks,
Paul

[CeePo]

maybe, when I come across an older fw version. but since I am in no specific hurry I might as well wait and see with what you come up with... thanks anyway.
cheers,
CeePo

[Bernhard Steinert]

Hi CheePo,

Hi Paul,

i have tested a second thermostat and a ecobutton tonight, both working very well! I also use fw 1.61 on my busware cul and have no problems. @CheePo, i think your problem is not the the fw.

thanks for your great work Paul! :)

cheers

  Bernhard

--

[Paul Hampson]

Hmm... given what Bernhard has said this is very strange. The culfw command reference states:

Z<func>[<hex>]
    MORITZ (aka MAX!) mode. <func> is one of:
        r - enable MORITZ reception. Note: only MORITZ messages will be received in this mode. Data is reported in hex. If bit 4 was set in previous X cmd (i.e. X10) reported data is binary.

This seems to suggest what ceepo is seeing is correct behaviour - data comes out in binary, but what we observe on our sticks is not correct according to the above statement i.e. we get hex reported.

At this point I don't know why there is the difference in behaviour...

I'll investigate some more when I get chance.

Berhard- glad you are having a good experience!

Thanks
Paul

[CeePo]

strange indeed! and what if the X10 command would be dropped?
In cutecom, when I send >Zr< I can watch thermostat and CUL happily exchange messages.
just a guess...
cheers
CeePo

[Paul Hampson]

Hi Ceepo,

Yes. I think I'll try that first. Should be a quick change. I'll post an updated jat here in the next few days

Thanks
Paul

[paul....@gmail.com]

Dear Paul,
I have a Max!Cube, 2x Max!Radiatorvalves, Max! Adapater Plug (http://www.conrad.com/ce/en/product/449236/eQ-3----MAX----Connectoractuator), Openhab and a CUL installed.
I was hoping I could use the Max! CUL binding to control the my heating system via the Max! Adapter plug.
I realize that this device is not included in the binding.
Is there I way I could include it. I hope it is not to difficult, since it is a simple switch.
Thank you in advance for your help.
Kind regards,
Paul

[Paul Hampson]

Hi Paul,

Thanks for your willingness to give this binding a go. I can certainly try to add the adapter but I'll need you do the following though as I don't have an adapter plug myself:

1) Setup the CUL and binding and put the binding into listen mode with DEBUG logging.

2) Go through the normal pairing procedure for the Max! Adapter with the Cube and provide me with the log output in listen mode

3) Turn the Max! Adapter on and off with the cube and provide me with the log output in listen mode

Hopefully this will give me enough information to implement it (there may be new message types etc).

Thanks,

Paul

Paul

[CeePo]

Hello Paul,

guess what, it's working now. I tried today (using the 1.6 binding/transport files) and actually got the cul and the radiatorthermostat to pair.
The whole debug output now looks completetely different than before, even though the X21 command is still issued.
So thanks, I think I can start building my max system now.
cheers,
CeePo

[ernoutva...@gmail.com]

Hi Paul,

Thanks for the great work on the maxcul binding!

I do have some issues with pairing my max radiator items though. 

I do see a pairing ping - but it looks like my system replies with a different type of ACK which is not accepted by the binding.

I've got a CUL stick with 1.16 on it - but saw online others had it working with that version as well.

I have put the binding in listen mode and captured the messages that are exchanged when the max! cube pairs with my radiator.

(see attachment).

My radiator device id's start with KEQ instead of JEQ - so maybe this is another gen of products?

Would be great if you could point me in the right direction.

Thanks!!

Ernout

Op vrijdag 23 mei 2014 01:26:19 UTC+2 schreef Paul Hampson:

[Paul Hampson]

Are you referring to this line?

2014-11-30 20:41:18 ERROR o.o.b.m.i.messages.AckMsg[:32]- Got ACK message with incorrect length!

This is in fact normal (I should probably fix this!).

Are your devices pairing with the CUL stick running with openhab? If not then please make sure your devices are factory reset before pairing otherwise they try and pair with the previous controller.

If you still have trouble can you send me a log of the pairing process with your stick.

Thanks
Paul

--

[Bernhard Steinert]

Hi Ernout,

i don't think there is a problem with different gernerations, i have KEQ and IEQ devices and they are working fine!

did you paired this devices with max!cube before? ..i had to completely reset the devices to get them paired with my maxcul setup!

cheers

  Bernhard

--

[ernoutva...@gmail.com]

Hi!

This worked. I had reset the devices before, but now I had pairing switched on in MaxCul/openhab while resetting the device.

Then the device was added to the config.

Great! Thanks for the tip!

Ernout

Op woensdag 3 december 2014 10:31:17 UTC+1 schreef Bernhard Steinert:

[Simon]

Hi Paul,

thank you for your great work!

After setting up binding, items, and sitemap for my living room (1 wall therm., 2 radiator therm.), everything worked at first. After some while, however (I think it was after I experimented with the associations), updates of openHAB items were not transmitted to the devices anymore. The debug output of your binding showed exceptions, e.g., when sending values to the CUL stick (see below). Copying the raw data in MAX format and pasting it to the CUL serial device directly (i.e., using a terminal application) worked and the correct target temperatures were set. 

I could not solve it and instead reset everything and gave it a second try. Sending and receiving works again now, however, the same exceptions are thrown and I thought you might have a look at it.

Some environment details: OpenHAB 1.6.2., CUL Stick V3 with firmware v1.62, Raspberry PI B+ @ Linux raspberrypi 3.12.28+

The following briefly describes what I did and the corresponding debug output of openHAB is attached:

• CUL Stick fresh firmware flash, reset all MAX devices
• First start of freshly installed openHAB
• Pairing of the wall thermostat (00:09:25.646 in the log) -> This caused repated sending of ADD_LINK_PARTNER messages, until all transfer credit was consumed @ 00:10:00.125
  
• The first exception is thrown a while after @ 00:11:55.214
• I restarted openHAB for whatever reason..
• Sending values to and receiving values from the wall thermostat works, but an exception is thrown when values are changed in the openHAB webinterface and sent. (This exception is always thrown when sending values, however, they do not appear in my debug log, so I copied it only ONCE to the attached log file @ 00:19:44.563, where it was thrown the first time)
• Pairing of a radiator thermostat @ 00:24:23.155 -> No repeated sending here, but again exception a while after @ 00:29:30.362
• Openhab receives and displays values of the radiator therm.!
  
• Wait a while for more credit :-) changes were successfully converted to SLOW messages and transmitted to the radiator therm., however, as for the wall therm., exceptions are thrown when sending as demonstrated @ 00:34:40.048

Items:

Switch maxPairMode { maxcul="PairMode" }

Number lrWtTarget { maxcul="WallThermostat:LEQ0XXXXXX:feature=thermostat" }

Number lrRtSouthTarget { maxcul="RadiatorThermostat:KEQ1XXXXXX:feature=thermostat" }

Sitemap:

Switch item=maxPairMode label="CUL Stick Pair Mode"

Setpoint item=lrWtTarget minValue=14 maxValue=28 step=0.5 label="WZ WT Temp. Soll [%.1f °C]"

Setpoint item=lrRtSouthTarget minValue=14 maxValue=28 step=0.5 label="WZ RT Süd Temp. Soll [%.1f °C]"

Thanks,

Simon

[Paul Hampson]

Hi Simon,

Thanks for your input. As you have noticed the pairing process is not as reliable as it should be. I've yet to work out why this is as I think we do everything in a pretty similar way to the way the Cube interacts with the devices. I have had cases where I have had to pair stuff multiple times to get all the settings to apply. In these cases you don't need to factory reset the device or put the binding into pairing mode, just hit the pairing button on the particular node device again. 

If you've got the time feel free to have a go at improving it! I've put some protocol documentation up here - http://the.cyclingengineer.co.uk/2015/02/01/max-thermostat-pairing-procedure-protocol-information/. Currently I don't really have the time to put into it at the moment, but I've had a quick look at the code pointed to in the exceptions and they aren't anything major. It's just a result of having no associations I think. It's an easy tidy up to fix this exception. I'll put in a PR soon.

 Thanks,

Paul

--

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/T61K_PRC9o8/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/9cec1e1d-8cbe-492a-9a91-aeca9efb4ec6%40googlegroups.com.

[Re Ch]

Hi Paul,

I am planning to set up the MAX CUL binding for my home.

Can you tell whether it is possible to use the "Mobilcom Debitel Smarthome" devices instead of the ELV ones?

As far as I know the hardware is identical but there is an "artificial incompatibility" established between ELV and MD devices. 

I think the serial numbers are registered somewhere and the systems refuse to pair with devices which have serial numbers of the other brand.

So the question is: will this binding be able to use any device or do they have to be original ELV ones?

Thx,

chris

[Paul Hampson]

Hi Chris,

I have never heard of these devices so cant say yes or no.

We don't do any validation of the serial numbers with any third party so if that is the mechanism that they use then it won't affect the binding operation. If they have changed the actual protocol then it might be a bit trickier.

It would be interesting to here if it does work.

Thanks
Paul

--

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/T61K_PRC9o8/unsubscribe.
To unsubscribe from this group and all its topics, 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/f0af0bd3-b85d-4a92-96ad-828737a29923%40googlegroups.com.

[Re Ch]

Hi Paul,

thx for your quick reply!

I ordered a CUL stick and a set of hardware.

I will give it a try and keep you updated.

The advantage of the MD - devices is that they have a kind of leasing model. 

The hardware sells really cheap but using the cube with their service costs a monthly fee.

This is the reason whey these devices sell much cheaper on ebay than the ELV devices.

However this can be quite an advantage if their service is not required.

As I want to install radiator thermostats in my entire house I need quite a few devices ...

chris

[Simon]

Hi Paul,

thanks for your reply and advice!

For now my living room setup works relatively robust despite some expections beeing thrown. Indeed I thought about getting my feet wet with the OpenHAB and MAX! CUL binding sources, however, I have to postpone that for reasons of time :(

As I integrate more rooms, I will at least keep writing here about any interesting issues I might experience...

Cheers

simon

[Re Ch]

Meanwhile the hardware (MD-devices and a CUL-stick) has arrived and I can confirm that my tests were successfull. 

I connected the MD-devices to homegear and the binding is working well with this setup ! 

No MD-software is involved - so it is possible to use the cheap hardware without monthly fees.

The Homematic/Max -binding also works when the cube is used but it is quite unreliable, has a high latency and the auto-discovery does not work (the IP adress of the cube must be entered manually)

chris