Updated November 2016 to completely remove credits handling so there is no restriction on transmission

I’ve recently purchased 10 of the eq3 MAX! central heating thermostats (TRV replacements) as well as 3 shutter contacts and 2 eco switches from conrad electronics. I also bought the MAX! cube but then decided to use a CUL device from busware.de to control them using FHEM because this allows for easier interaction with them and use of the eco switches directly.

I soon discovered a problem in that when I tried to send a command to all of them (eg. set desired temperature) I very quickly “ran out of credit” with messages in the FHEM logs like “CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 115. Waiting 113 seconds” and I couldn’t do anything practical with them.

Stuck microswitch?

I’ve depressed the microswitch too many times so that it got stuck. This means it’s always in bootloader mode. To workaround this you can use a udev rule (disable it if you want to program the device!)”.

Add to /etc/udev/rules.d/99-usb-serial.rules (also adds a symlink to /dev/cul for the real device):

Hi Matthew,
thanks for your proposal to fix the Max! credit problem.
I’m using a CUNO2 and I followed your instructions – unfortunately without success. Flashing was without any error. Now I get often the message “…disconnected, waiting to reappear…”
Could you give me any hint?
Regards
Walter

I presume that this did make a difference? I’m about to try some of these devices and I have a CUL already. I have heard about this sort of thing as causing trouble so would be great if this provided a solution.

thanks for this – it seems like this doesn’t solve the problem entirely, since you only modify the maximum burst length, so you can send 72 second bursts instead of 9 second bursts. If you have exhausted the 72 seconds, you have then used up the allowed airtime for 2 hours. It helps with sending initial configuration data, but if you run into the 1% rule during regular operation, you still have a problem…

Not being a programmer I have been unable to updat the culfw v2 for my CUNX. CUNX is so much more flexible than CUL so keen to use them as part of future expansion. Can you provide any guidance on exactly how to modify the V2 firmware for CUNX – I have enough expertise to do the flashing but not the coding/recompiling?

Note that I am no longer using my CUNX for MAX eq-3 as I had some weird behaviour.
Instead I have reflashed my MAX Cube with the ARM version of culfw – also with credit checking turned off.
However I was still getting a lot of bad data being returned and I have tracked it down to a piece of code in the firmware that seems to me to be completely wrong. If it was given a length byte for an eq-3 message that was too large it just read 29 bytes regardless and returned it – hence passinf rubbish back to fhem and also consuming potentioally vaild data that followed. So I changed that code in the ARM version and my system is now a lot more stable.

Where can i find information about flashing MAX cube with custome firmware?
Im currently having issue with my wall thermostate. Both are flashing quickly sugesting that its out of credit. Trying to find a solution for this. Any help is appricated.
Regards,
Jonas

hi, this cul-firmware was music in my ears 😉 so i flashed this cul-firmware…

today morning one MAX-HeatingThermostat switched (it was set to ECO-Mode) to 12 degrees
* eco temperature is 17 degrees and there is no setting in the temp with 12 degrees, i changed the window-open-temperature to 11.5 degrees a year ago…)
* and some time later a Wall-Thermostat made first a “BOOST” and three minutes later it went to 22 degrees, it was in eco mode before, too…

No “set … 12 degrees” or “set mode boost…” or “set desired-temperature 22” in my them.cfg, which has been unchanged regarding MAX/Heating-Settings for a while…

no entry in the current fhem.log…

I can’t believe this cul-firmware leads to transmission-errors which are understood by some random-max-devices setting wrong temperatures!?

Hi Matthew,
I made the CUNX changes locally to v2 of culfw
I don’t know how to feed the changes back (and I don’t think the official culfw site would welcome them!)
The ARM version changes I made to my Cube – to correct the over length handling ‘error’ were also made locally. I have not included them in the CUNX build as I have no way of testing it at the moment (as I am not using my CUNX).

The length handling error exists in the mainline version and has just been ported to ARM.
If I spoke German I would have raised the issue with the author.
But it is working a lot better after my simple fix.

Hi Matthew,
I changed two files: rf_moritz.h and rf_moritz.c.
For the .h file I just added a new constant for minimum message length. I think that is actually 12 but, being cautious I set it to 10:
————————————
#ifndef _RF_MORITZ_H
#define _RF_MORITZ_H

For the .c file I just changed some logic in rf_moritz_task in order to sanity check the length byte and return if it is out of range:

——————————-
//AGW** change validation to exit if too long or too short, rather than just limiting
// max length
if (enc[0]>=MAX_MORITZ_MSG || enc[0]<=MIN_MORITZ_MSG)
return;
// enc[0] = MAX_MORITZ_MSG-1; – this is original code
——————————–
This starts at line 221 in my copy.

i have the credit Problem. So i found your Page/github. But i have a nanoCUL, i build with Parts from the net. It seems that the Firmware of the naoCUL is not modified. Is it possible that you alter the nanoCUL firmware so i can use it on my diy CUL? Thanks for the great work!!

Thank you Matthew – great work – I’ve been running without credits for months now and no problems at all.
Just a note that the revised version 1.66_nocredits causes this (ignorable) error in fhem log:
PERL WARNING: Argument “66_nocredits” isn’t numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145.

I am unable to comlile the FW anymore (on Fedora 28) . Woluld you be so kind to let the compiled CUL_V3.hex available for download?

The CUL_V3.hex is successfully created, but when i upload to the device, the USB device don’t come up anymore , and kernel reports the following error: usb 1-1.6.2: device descriptor read/64, error -32.
The green led blinks as normal anyhow.