MAX eq-3 with CUNX rather than MAX Cube

[alangward]

Hi,
I've had a eq-3 configuration for quite a while - using a MAX Cube.

I have been controlling my boiler with fhem and a small perl module that I have written, which detects demand from any room rather than just a central thermostat.
It works fine and I am happy with it.

The only problem is the unreliability of the MAX Cube. It occasionally loses its memory and I have to re-pair all my devices.
To circumvent this problem I am trying to replaced the Cube with a CUNX.
I have had some success, but am unable to send commands via the CUNX to the devices.

I realised after a while that this was probably because the devices were still paired to the CUBE. So I have factory reset one device (Wall thermometer) and it now responds to local Menu commands (which it doesn't if it thinks it is paired to a Cube).

I have tried to pair it to the CUNX connection and I get messages in the log (if I set verbose to 5) saying that the pairing is being attempted, but I still can't update the settings on the device (such as desiredTemperature).

Has anyone got any idea how I can overcome this last hurdle?

Thanks,
Alan

[fruit]

I am not sure what a CUNX is but I switched to an RFBee to replace my Cube recently and I have

Code Auswählen Erweitern

define RFbee CUL /dev/ttyUSB2@38400 1234
attr RFbee rfmode MAX

Assuming you had to build and flash the firmware are there any compile options you should have used during the build?

The changeover here from the Cube required re-pairing all devices but I had a problem with one window switch that would not pair at all - I suspect it has simply failed internally

[alangward]

Thanks for the reply.

The CUNX is the latest ethernet-attached variant of the CUL from busware.de.
I didn't build the binary for the CUNX. I used the existing image from GitHub to flash it and as it appeared to work OK I assumed that I had done the right thing.

There is a CUL-MAX module that is present to support this style of working.
It maybe that it doesn't properly support this variant of the CUL.
My plan is to try and debug this module to see what is going on.

I hoped someone might have a ready made answer.

[fruit]

The CUNX is the latest ethernet-attached variant of the CUL from busware.de.

I should have looked there!

I didn't build the binary for the CUNX. I used the existing image from GitHub to flash it and as it appeared to work OK I assumed that I had done the right thing.

I'd assume so too

There is a CUL-MAX module that is present to support this style of working.
It maybe that it doesn't properly support this variant of the CUL.
My plan is to try and debug this module to see what is going on.

I guess it has the same culfw as I built in which case a number of protocols are built as standard including moritz for MAX

I hoped someone might have a ready made answer.

If you do a search for CUNX CUBE from the main Search (top LHS of screen) you will see a number of hits that may be of use - if can unravel google translate

Edit: I got my culfw from here http://culfw.de/culfw-1.61.tar.gz

[alangward]

Thanks for the reply.
The CUNX requires version 2 of culfw.
The version I am using is 2.66.

There appears to be a disconnect, however, between the documentation and the behaviour of the device. In particular the commands to set up a static IP address are not recognised.
This leads me to believe that there may also be a disconnect between the CUL-MAX module and the culfw.
Which is why I plan to debug what's happening.

[alangward]

Further Update - Success

I have solved my problems and my eq-3 system is working fine with the CUNX.

The difficulty was that all the devices except 1 were still paired to the CUBE as I didn't relish having to factory reset them all (just yet). Hence they were not responding to messages from the CUL_MAX module and its outbound queue filled up - this prevented the timely pairing of the one device I was trying to test.

I thought of a "cunning plan". I disconnected the Cube and changed the RF address on the CUNX to be the same as the Cube - hence conning all my devices into thinking they were still talking the same 'central' device.
I was then able to re-pair the device I was testing - and it all works.

I just have to implement a module to handle the Eco Switch. I have already coded it just need to test it.

[fruit]

Well done. Unpairing and re-pairing is a chore but only needs to be done once - unlike the Cube when it fogets all settings!

For my Eco switch I used the method given in http://www.fhemwiki.de/wiki/MAX!CubeMigrationToFhem

[alangward]

Hi,
I tried using the method suggested, but had no success with it - and I gave up trying to find out why not!
I'm also not comfortable coding a list if devices that may change in the future.
So I have gone back to me own little module that enumerates all the required devices and it now works fine - although the CUNX route is a bit sluggish in getting the commands to all devices.
I suspect the Cube may have some broadcast mechanism for this.

I'm now picking up rubbish from my weather station and (I think) those of my neighbours - so the log hasa lot of error messages for unrecognised message type. I have set all these devices to ignore=1, which helps, but I'm still getting some errors.

However, the system is working fine. 

[fruit]

Did you perhaps forget <struct_type> as I did first time? I now have

Code Auswählen Erweitern

define AllHeaters structure AllRads MAX_075bd4 MAX_075be0 MAX_075bdc MAX_0759c6 MAX_075bb2
I heven't found a specific definition of what <struct_type> should be but it appears to be free-form - and that works here.
Devices can be added/removed as needed, don't see that as an issue but your setup may be more complex than mine.

My feeling is that the Cube queues relatively silently compared to CUL devices so we just see more log entiries now. Heating season not started yet so my opinion may change

Edit:I think that <struct_type> should be set same as the devices type ie. MAX

[alangward]

Hi,
I say that it is sluggish, because if I use the Eco Switch with the Cube all the thermostats change to there Eco temperature almost instantly (as observed on the display of the radiator valves.
With my new set up it seems to take several minutes for the command to propagate to all of them - not that speed is important.

I'm experimenting with some changes to CUL_MAX to try and improve its handling of 'ignored' devices.

[dromer1967]

I'm also struggling with the (lack of) reliability of the Max! Cube.

Can perhaps you confirm that when using the CUL there are no issues and that the Max! hardware then works reliable?

My issues with the Cube:
-When setting the setpoint for Thermostat A, Thermostat B sometimes also gets the same setpoint as A
-Sometimes a thermostat or a valve stops reporting to the Cube. It responds to temperature commands but valve information is no longer received.
-Sometimes the Cube! stops updating data alltogether and is has to be rebooted.

Do you or anyone know if these problems are fixed when using the CUL?

In itself I find the Max! system very nice but due to the unreliability of it it gets very frustrating.

Regards,
Peter

[fruit]

My RFBee CUL has been working OK.
I feel that stat updates back to it are slower than the Cube but it is very early in the heating season and changes are fewer than when colder. I have just installed MaxScanner to try and improve that.

Your list of problems suggests that you may have poor reception of signals. Can you move the Cube to test that?
If closer stats are more reliable than those further away that might be proof enough

Reports from others are that CUL is more reliable. I can only say that it hasn't fallen over here yet but I only had about three fails in three years with the Cube

[dromer1967]

I have tried to move the Cube around but I think the problem is in the firmware of the Cube though I'm no expert on that.

For example I have thermostats in use in 5 rooms. Two of which always work (one on the same floor and one on the floor below). And three of them have issue (both on the same floor as on the floor below).

I can set room A for 19 degrees and that works. But after some minutes the temperature is reset to 15 degrees which happens to be the setpoint of another thermostat. So the signals get confused and I don't think that is a reception issue.

I wouldn't mind investing in a CUL but if the problems there remain the same then it is perhaps time to migrate to something else.

The problem of that being.. I haven't got a clue which system I should choose which is both affordable ánd reliable.

[fruit]

Perhaps you could try simply swapping one of the OK stats with one of the others? You could probably try this without messing with configs as a test, simply unscrew and swap over

The other two sound as though they might be paired/associated with each other - assuming you don't have a wall stat linking them
You could try and disassociate them through fhem or do a factory reset on both and re-teach

[dromer1967]

Thanks for all the tips, fruit.

Unfortunately I have already done all you said and more than once believe you me.

After unpairing and factory reset and then associate again, all works fine for a while. But after time the problems occur again.

It's that what makes this system quite unreliable