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 

[fruit]

Very frustrating I imagine.
You don't know if it's the Cube or stats at fault except that several stats misbehaving would suggest Cube - I know you are already there

As far as I am aware it's possible to run a CUL alongside the Cube and monitor the stats. I think there is a thread here in the English section mentioning this.

If you have suitable hardware seems best to flash with culfw and watch.
I chose RFBee on an XBee-Explorer as the cheapest readily available option, there are many other choices (incl. DIY) but I don't know of a list of suitable devices

[dromer1967]

Indeed have I thought for a while that it could be a stat. But after resetting so many times I am fed up with it 

An RFBee sounds nice, but I'm a software developer and not so very much a hard ware guy. So I don't know ifa RFBee is doable for a novice on that subject?

Can you point me in the direction of what is needed for the RFBee on an XBee-Explorer? In matter of which hard ware (shop?) and how difficult to flash?

[chris1284]

why no one flashed the aculf on the cube?

https://forum.fhem.de/index.php?topic=38404.0

that solves the max-cube problems with config lose and you need not to buy other iODevs (like cul or rfbee). After this you can use the old cube as cuno / cul via lan / usb


stable and done in max 5 minutes

[dromer1967]

The answer to that question for me is simple: I don't dare to take the risk.

-You have to open the Cube case and connect some pins
-You have to flash the device with boot loader and all

When something goes wrong (which can happen if you have no experience with this) you have a dead Cube which results in an unuable system alltogether.

Besides that I have written some software which talks to the Cube. I'm sure the protocol will be entirely different after flashing aculf.

[fruit]

The answer to that question for me is simple: I don't dare to take the risk.

I felt the same hence the RFBee.

Hardware http://skpang.co.uk/catalog/rfbee-v11-wireless-arduino-compatible-node-868mhz-p-815.html and http://skpang.co.uk/catalog/xbee-explorer-usb-p-406.html, plenty of other sources including ebay

The rest at http://culfw.de/culfw.html, all pretty simple.

RFBee and Xplorer board is fine despite some pin differences (we are only interested in the ones that are exactly the same) so just plug in USB, flash and go, nothing more to it

[chris1284]

naja, its a minimal risk. nobody of the noobs have destroyed the cube. for the pin connecting I had used a screwdriver. the only very goog reason is your own software.
in order to minimize the risk, use a second (used) cube (which is cheaper than a rfbee with explorer)

[dromer1967]

The question is how many NOOBS have really tried it 

But your tip on a second Cube is a good one! It's indeed cheap so I could use one to try it out.

Will do

[dromer1967]

I felt the same hence the RFBee.

Hardware http://skpang.co.uk/catalog/rfbee-v11-wireless-arduino-compatible-node-868mhz-p-815.html and http://skpang.co.uk/catalog/xbee-explorer-usb-p-406.html, plenty of other sources including ebay

The rest at http://culfw.de/culfw.html, all pretty simple.

RFBee and Xplorer board is fine despite some pin differences (we are only interested in the ones that are exactly the same) so just plug in USB, flash and go, nothing more to it

Thanks for the links Fruit! Had missed them earlier.

perhaps I will try this. On the other hand the Cube, which Chris suggested, is about the same price and has a casing included. Perhaps that's the easiest way.

[ggaljoen]

Just had to read this topic a few times and was convinced I should flash my -memory losing- cube.

For the bootloader I did not teamed up with sam-ba, I used the bossa version http://www.shumatech.com/web/products/bossa with succes.
The firmware did I with http://ttssh2.osdn.jp/index.html.en
And it was... EASY to do, I can only recommand it.

[dromer1967]

I would be very interested to know how this works out for you. If the Cube is (finally) stable when using this firmware.

It would be my first firmware flash so I'm not yet convinced it is easy 

[ggaljoen]

First LAN connection tests no succes got every time it need to send something '3: Not enough credit: 0' for the OLD CUL0
But when I check: get credits10ms is never 0 for the NEW CUBe
I am goning check the german part for answers...
Blame it on ME = : script refered to the CUL0 and not to the newly CUBe!

Running GREAT! (now)

[fruit]

culfw does seem to make a lot more noise when credits are limited than the Cube but I suspect only because the Cube hides a lot more
They should both be trasnsmitting obeying the 1% rule

[ggaljoen]

culfw does seem to make a lot more noise when credits are limited than the Cube but I suspect only because the Cube hides a lot more

The (culfw) QUEUE catch this 'out of credits' 1% limitation and keeps on trying until transmission succeeded

[ggaljoen]

I would be very interested to know how this works out for you. If the Cube is (finally) stable when using this firmware.

Time will tell but for now everything is running fine!

It would be my first firmware flash so I'm not yet convinced it is easy 

Even your cell phone got flashed (updated) every now and then...

[fruit]

The (culfw) QUEUE catch this 'out of credits' 1% limitation and keeps on trying until transmission succeeded

So does the Cube but I only remember seeing a few messages eg. when updating weekProfiles on several stats. I probably still have the logs somewhere

It's also quite noticeable when using the MAX Eco-switch under CUL as this requires sending desiredTemperature to each stat.
I think the Cube may use a short command over RF though I cannot remember reading anything about it when I was looking around at MAX protocols

[dromer1967]

Even your cell phone got flashed (updated) every now and then...

That's right but I didn't have to open it and put a jumper on some pins 

[ggaljoen]

That's right but I didn't have to open it and put a jumper on some pins 

IF you can place a paperclip on some sheets, you can do this; in fact you could use the same paperclip to do the trick 

[alangward]

Hi,
I haven't looked at this forum for a while.
My set up with a CUNX is working pretty well.
Certainly a lot better than the Cube it replaces.

My only problem is that I am receiving long bursts of garbage messages that sometimes swamp communication between the devices and the CUNX.
I am at a loss to know what the problem is, but they seem to be triggered by the sending of a command to turn the boiler on - not always, but there is a distinct correlation.
They are often longer than the 30 byte limit imposed by rf.moritz.c. I am thinking of hacking that to increase the limit and see what I am really receiving.

If you can believe the RSSI number, most of the messages must be fairly local, but some are further away. I live in the country so any neighbours are at a distance of several hundred metres.

I did wonder if it was due to collisions between local devices transmitting at the same time, but it carries on for too long for that to be  a reasonable assumption.

It would be reat if anybody had any ideas on this.

Thanks,
Alan