Is ELV Max! a reliable system compared to FHT80b (or ZWAVE)

[pbrand]

I was wondering what the experiences are with users of the ELV MAX! system? Is it more reliable than for example the FHT 80b's?

I am looking to upgrade my current heating system (which uses FHT80b's). It works OK when you don't touch it, but there are irritating issues:

-The system is not fully bidirectional. You can send a command to a FHT80b thermostat but there is no feedback whether is has been received (other than waiting a couple of minutes to get a status update);
-At times the system seems to upset itself, resulting in total lack of response to anything something for half a day up; Quite irritating if you come home in winter and the house is cold
-Response is quite slow. You can send a command every two minutes, but frequently they do not arrive properly. So it can sometimes take up to 15-30 minutes before the valves react;

ZWAVE doesn't seem to have these problems (bidirectional and autorouting), but Danfoss thermostatic valves seem to be the only possibility are they are not very cheap (if you need 9 of them).

I wonder is MAX! also doesn't have the mentioned problems?
-Is it bidirectional (commands sent are always received and reacted upon)?
-Does it keep on working for a longer period?
-Is it more responsive than FHT80b, e.g. it doesn't take 15-30 minutes to get a valve to react?
-And lastly, is there some signal in the MAX Cube that heating is needed? This because I have city heating and I need to open/close the valve which circulates the hot water.

Or is ZWAVE the better solution? And are there alternatives to Danfoss?

Hope someone can shed some light to the subject

[pbrand]

No one who can shed some light on this subject?

[matthijskooijman]

I've been playing with ELV Max! for a while last winter, and expect to completely implement it the coming winter. I don't have a perfect view yet, but I can answer some of your questions.

ELV Max! is a bidirectional system, and I think that every packet is actively ACKed (not 100% sure, though).

I didn't have problems with my thermostats running for a while, though I haven't been using them very intensively yet.

If I send a new temperature to a valve, or turn the dial on the valve itself to set a new temperature, it usually starts changing the valve value almost immediately. A valve status update is usually also sent within 30 seconds, IIRC.

I don't think there is any "I need hot water" signal in the cube. However, in the "L" response for each valve it should show the current valve position. I'm not really sure how often that's updated, but I'd expect it to be available fairly quick (unlike the "current temperature" value, which is only sent whenever the valve actually changes, not on every temperature change). You could use the valve positions to decide wether heat is needed (I plan to do something like that to control my boiler, except I'm considering to sniffing RF instead of connecting to the cube).

However, if you have city heating, can't you just keep the main valve open and let your radiator thermostats shut off each individual valve if they don't need any heat? I thought the city heating scenario was exactly what the Max! system was designed for, since it does not have any official boiler control component).

[sj3fk3]

I wonder is MAX! also doesn't have the mentioned problems?
-Is it bidirectional (commands sent are always received and reacted upon)?
-Does it keep on working for a longer period?
-Is it more responsive than FHT80b, e.g. it doesn't take 15-30 minutes to get a valve to react?
-And lastly, is there some signal in the MAX Cube that heating is needed? This because I have city heating and I need to open/close the valve which circulates the hot water.

Hope someone can shed some light to the subject

I've been using MAX! for over an year now and I can say it's rock solid. There is more information flowing back and forth from the cube to the radiator thermostats then the default application shows but with http://www.maxbuddy.de/ or other 3rd party domotica software you can get a lot more information.

I'm very happy with the ability to warm rooms when needed instead of the whole house either on or off. If you get it to work with your domotica server and an OpenTherm gateway, you have the ultimate IMHO.

[richard naninck]

ELV Max seems to be the next generation so it probably is better than the FHT80b. However I don't get the irritating stuff you are getting.
I use 10 FHT80b's in 10 different rooms with a total of 13 valves. All of them are controlled using my own written software and an FHZ1300PC. The interface also controls about 50 other FS20 devices in the house and I never get the flooding you are talking about. If the PC interface gets too many messages, it will stop working like it should until the buffer is cleared.
You can recognise the messages received when this is happening. I first got that during lots of testing but never during normal ops. If you read the manual of a PIRA, you can read that the interval should not be set @ 8 seconds to produce a message in an envirenmont where much motion can be registered because it will flood the system.
Arming the alarm, sets all 10 FHT's back to 15 C in about one second and it takes up to 2 minutes before all FHT's ack their new status. Als the valves don't take long to respond to the FHT as soon as the FHT updated its status.

ELV looks nice but maybe a simple change in how you use the FHT can save you money..

-The system is not fully bidirectional. You can send a command to a FHT80b thermostat but there is no feedback whether is has been received (other than waiting a couple of minutes to get a status update);
-At times the system seems to upset itself, resulting in total lack of response to anything something for half a day up; Quite irritating if you come home in winter and the house is cold
-Response is quite slow. You can send a command every two minutes, but frequently they do not arrive properly. So it can sometimes take up to 15-30 minutes before the valves react;

[pbrand]

I've been playing with ELV Max! for a while last winter, and expect to completely implement it the coming winter. I don't have a perfect view yet, but I can answer some of your questions.

ELV Max! is a bidirectional system, and I think that every packet is actively ACKed (not 100% sure, though).

I didn't have problems with my thermostats running for a while, though I haven't been using them very intensively yet.

If I send a new temperature to a valve, or turn the dial on the valve itself to set a new temperature, it usually starts changing the valve value almost immediately. A valve status update is usually also sent within 30 seconds, IIRC.

I don't think there is any "I need hot water" signal in the cube. However, in the "L" response for each valve it should show the current valve position. I'm not really sure how often that's updated, but I'd expect it to be available fairly quick (unlike the "current temperature" value, which is only sent whenever the valve actually changes, not on every temperature change). You could use the valve positions to decide wether heat is needed (I plan to do something like that to control my boiler, except I'm considering to sniffing RF instead of connecting to the cube).

However, if you have city heating, can't you just keep the main valve open and let your radiator thermostats shut off each individual valve if they don't need any heat? I thought the city heating scenario was exactly what the Max! system was designed for, since it does not have any official boiler control component).

Thanks for the response. Since there was no response at all for quite some time, I forgot this topic so I only see now that there have been reactions. Great

Of course I could leave the valve of the city heating system open all the time, but if there is no need for heat, this would be a waste of energy (and more importantly my money ) Because although the radiators would be closed, there are still the pipes connecting them in which the boiler water would circulate and there consume energy.

Since my FHT system seems to get more quirks lately, I'm strongly considering this system. Do you need the room thermostats to operate the systems or are the radioatorvalves enough? What is the benefit of the room thermostat?

[pbrand]

ELV Max seems to be the next generation so it probably is better than the FHT80b. However I don't get the irritating stuff you are getting.
I use 10 FHT80b's in 10 different rooms with a total of 13 valves. All of them are controlled using my own written software and an FHZ1300PC. The interface also controls about 50 other FS20 devices in the house and I never get the flooding you are talking about. If the PC interface gets too many messages, it will stop working like it should until the buffer is cleared.
You can recognise the messages received when this is happening. I first got that during lots of testing but never during normal ops. If you read the manual of a PIRA, you can read that the interval should not be set @ 8 seconds to produce a message in an envirenmont where much motion can be registered because it will flood the system.
Arming the alarm, sets all 10 FHT's back to 15 C in about one second and it takes up to 2 minutes before all FHT's ack their new status. Als the valves don't take long to respond to the FHT as soon as the FHT updated its status.

Richard, can you elaborate on this some more? I don't exactly understand all you're saying here. And since my system became unresponsive again twice in the last week it's quite irritating. What I also have encountered is that the valve in the bed room lost íts sync with the thermostat. And this occurred in the hobby room too at roughly the same time. I manually had to resync them. I don't understand why this is happening suddenly and to more than one room.

Can you elaborate some more on the message you receive when the flooding occurs? I didn't know you could detect that. I also use the FHS1300PC with own written software and it could be nice to incorporate this check in the program so I can build some sort of resting period when flooding occurs.

The FHT system can run for months in a row without a problem and then become unresponsive several times a week. I can't detect a system in that. If it becomes unresponive I have to shut down my software and let all thermostats 'be' for 12-24 hours before everything starts operating again. And coming home to a house in which the temperature is 16 degrees is not fun

Is the software you use private or can you share (some) of it? Perhaps you are using tricks I don't know of which prevent the system from overflowing?

[sj3fk3]

Of course I could leave the valve of the city heating system open all the time, but if there is no need for heat, this would be a waste of energy (and more importantly my money ) Because although the radiators would be closed, there are still the pipes connecting them in which the boiler water would circulate and there consume energy.

Since my FHT system seems to get more quirks lately, I'm strongly considering this system. Do you need the room thermostats to operate the systems or are the radioatorvalves enough? What is the benefit of the room thermostat?

All modern boilers shut off when the returning water is more or less just as warm as the outgoing water. If you close all valves the boiler will shut off. The room thermostats are nice to have but optional. They make for easy control of the temperature, plus they have the added bonus of measuring the temperature in a other area then right above the radiator (where the valve usually is). Personally I use sensors like the THGR810 to measure temp and hum in every room.

[pbrand]

All modern boilers shut off when the returning water is more or less just as warm as the outgoing water. If you close all valves the boiler will shut off. The room thermostats are nice to have but optional. They make for easy control of the temperature, plus they have the added bonus of measuring the temperature in a other area then right above the radiator (where the valve usually is). Personally I use sensors like the THGR810 to measure temp and hum in every room.

Like I said, I have city heating. So there is no boiler and therefore it won't automaticall shut down
Besides that I wonder if the boiler system would be something I wanted. Because, when the boiler has automatically shut down, it has to use some time interval to operate again (it can't measure the difference between incoming and outcoming temperature because when it is shut down there is no water flow). I gather this interval would not be one minute but more like five minutes.
Which means that it can take up to 5 minutes or so after operating a thermostat before the water is flowing again. I find this kind of response too slow.
Of course with a 'normal' heating system the thermostat is connected to the heating device and then you wouldn't have this problem.
But alas I have city heating

Thanks for the info on the thermostat. Indeed optional, but measuring the temperature in the room is something I would like to have so the room thermostat would be handy for that.

[richard naninck]

Richard, can you elaborate on this some more? I don't exactly understand all you're saying here. And since my system became unresponsive again twice in the last week it's quite irritating. What I also have encountered is that the valve in the bed room lost íts sync with the thermostat. And this occurred in the hobby room too at roughly the same time. I manually had to resync them. I don't understand why this is happening suddenly and to more than one room.

Can you elaborate some more on the message you receive when the flooding occurs? I didn't know you could detect that. I also use the FHS1300PC with own written software and it could be nice to incorporate this check in the program so I can build some sort of resting period when flooding occurs.

The FHT system can run for months in a row without a problem and then become unresponsive several times a week. I can't detect a system in that. If it becomes unresponive I have to shut down my software and let all thermostats 'be' for 12-24 hours before everything starts operating again. And coming home to a house in which the temperature is 16 degrees is not fun

Is the software you use private or can you share (some) of it? Perhaps you are using tricks I don't know of which prevent the system from overflowing?

All my scripts are open, but they are based on use with HouseBot so probably hard to use in your case.
Do you use other FS20 related stuff or just the FHT80b icw FHZ1300PC?
Each FHT80b produces 3 messages per hour containing temperature settings, battery stats etc. Once every 2 minutes you should see a message containing Valve data. Not sure who produces this message. (The FHT80b or the Valve itself).
Sometimes I don't get messages from the FHT80b anymore. I trigger myself by setting a timestamp on each received message. If the time from the last message is older than one hour, my system throws an error message and I up the FHT80b with 0.5 degrees. By doing this, almost Always the FHT comes back online. Actually it never goes offline because the valve continues to react to the FHT bu the FHZ1300PC simply doesn't get the messages anymore. Sometimes I also don't get the Valve messages anymore but as soon as a valve is controlled open again, the messages start flowing again. So often in summertime when the valve remain shut for months in a row I might loose the message stream. Mayby this is by design to save battery power. Not sure about that.

Flooding actually appears when too many messages are sent or received by the FHZ1300PC. This should normally not happen but while testing I have seen this a couple of times. I had to either wait a long time or unplug the FHZ1300PC to get it fixed again. That has something to do with the protocol itself because messages are buffered and communication with the FHT80b's is bidirectional.

[pbrand]

All my scripts are open, but they are based on use with HouseBot so probably hard to use in your case.
Do you use other FS20 related stuff or just the FHT80b icw FHZ1300PC?

I have some FS20 stuff (a sound signaller and some switches and a 220v socket switch). They always have trouble not responding well. I have a light in my bedroom whicih is switched through FS20. When I switch it off via software 1in 5-6 times it does not. And the device is only 6 meters aways from the FHZ1300PC (through some walls though). I got sort of used to this, but when the heating refuses to operate this is quite annoying.

Each FHT80b produces 3 messages per hour containing temperature settings, battery stats etc. Once every 2 minutes you should see a message containing Valve data. Not sure who produces this message. (The FHT80b or the Valve itself).

Okay, you mean that. Yes I know that too. I also keep track of the valve data message, because this is the trigger for me to send a new message to the FHT80B (about 2-3 seconds before the new valve data is about to be received). In this way the chance that the message is processed by the FHT80B seems to be the largest. Sending a new temperature also fails regularly (1 out of 4 times or so). My software therefore keeps a queue of transmitted temperatures and resends them when necessary (again when the receive window is about to open so every two minutes). This used to work reasonably well, but the last week the system has stopped to respond altogether.

Sometimes I don't get messages from the FHT80b anymore. I trigger myself by setting a timestamp on each received message. If the time from the last message is older than one hour, my system throws an error message and I up the FHT80b with 0.5 degrees. By doing this, almost Always the FHT comes back online. Actually it never goes offline because the valve continues to react to the FHT bu the FHZ1300PC simply doesn't get the messages anymore. Sometimes I also don't get the Valve messages anymore but as soon as a valve is controlled open again, the messages start flowing again. So often in summertime when the valve remain shut for months in a row I might loose the message stream. Mayby this is by design to save battery power. Not sure about that.

Indeed sometimes, (ahem), I also don't get messages from the FHT80B anymore. But when I then change the temperature that doesn't help because the system is totaly unresponsive. I have to stop controlling it, sometimes for more than a day, for it to come 'online' again. And ideed it never really goes offline, because you keep getting the valve messages. I don't think I overflow the system myself, because I always wait the 2 minute cycle to (re)send a message and always check the FHZ1300PC buffer to see if there are buffers available to send something in the first place.

I often see that the FHZ1300PC has few or no buffers available to send messages. But where this comes from, no idea.

Flooding actually appears when too many messages are sent or received by the FHZ1300PC. This should normally not happen but while testing I have seen this a couple of times. I had to either wait a long time or unplug the FHZ1300PC to get it fixed again. That has something to do with the protocol itself because messages are buffered and communication with the FHT80b's is bidirectional.

Flooding seems to occur regularly in my case. The FHT80B then locks itself up in its cocoon and stops listenig for a long time. This is quite anoyying. I can't find any system in it. Nor can I find a reason why the connection between FH80B an the valve is suddenly lost. Perhaps this stuff only lasts a few years and the breaks

I have put the FHT80B's in automatic mode now with a weekly schedule, so the house is not entirely cold when I get home. But this is a real step back in relation to my google calendar controlled software

I'm strongly considering (I think the chance that I will migrate is nearly 100% , but the financial aspect is also to be taken into account ) getting the MAX! components because at least they are fully bidirectional so I don't have to keep track myself if the thermostat has responded to a temperature change.

Also the MAX! seems to respond much faster when requesting a temperature change. In the case of the FHT80B, the 2 minute time window, and the fact it often 'misses' a change request, can cause a delay of 5-15 minutes before a temperature change is actually performed. I find this waiting time too long.

That point is also a nice opportunity to rewrite my software and use MQTT to transmit messages over the network so the system is less dependend of platform and implementation of the different components

[richard naninck]

Are you sure your software functions OK. Try to monitor the sent data from the PC to the FHZ1300PC. During the last hour I sent about 75 messages to the FHZ.
Heavy use of WiFi or making DECT / GSM phonecalls also jams the signal to where lights don't turn on anymore. Maybe you have some leaky signals. Maybe some wireless weather station with old batteries?

[pbrand]

I'm a professional software developer so yes I'm sure my software functions as it should

I have now totally removed the FHZ1300PC from the USB port and turned off my server for a while. Now, after rebooting and reconnecting, everything seems to work again.

But I totally have had it with this system and its quirks. I have ordered some MAX! equipment to investigate the transition to it, and a raspberry PI with razberry module to use ZWAVE for stuff other than the heating

Thanks for thinking along with me!

[richard naninck]

I'm a professional software developer so yes I'm sure my software functions as it should !

This ofter turns out to be a bold statement and thus not Always True

[pbrand]

I'm a professional software developer so yes I'm sure my software functions as it should !

This ofter turns out to be a bold statement and thus not Always True

Perhaps not Always true indeed

But with 23 years of experience I am now at last capable of telling if my own software works or not

Not saying that I programm bugfree. Bug it has been running for over a year so all the important bugs are now handled