forum

I am doing an air conditioning and floor project with the possibility of hot and cold (both in the air and on the floor) and it would be very useful to have specific ZUNO macros for this.
First of all, I want to indicate that I offer to do them myself. And I write this post to: first, request the opinion of the Z-wave.me team on whether they find it interesting to do these macros and; second, in case the answer was yes, request their technical support while I do the development (I have seen that the macros they are defined in the ZUNO_Definitions.h file, but I think I'm going to need more information to start creating the new macros).

Next, I indicate, in a preliminary way, what these macros would consist of:

• I thought that, in principle, macros would belong to the macro family ZUNO_SWITCH _...

• The first of the macros would be to control the operating mode of an air conditioning unit with the following options: OFF, COLD, HOT, AUTO, ON, FAN, DEHUMIDIFICATION.

• The second of the macros would be to control the operating speed of a fan coil unit. You should be able to choose one of several possible speeds.

• The third of the macros would be to control a group of underfloor heating valves and it should allow choosing that each of the valves works independently, with the possibility of ON / OFF in each valve. NOTE: I have seen that each valve can be controlled by assigning a ZUNO_SWITСH_BINARY () channel to each of the valves, but that consumes one ZUNO channel for each valve. My proposal has the purpose of saving ZUNO channels, using a kind of SWITCH_MULTICHANNEL for a group of valves independent of each other. I have tried to use a ZUNO_SWITCH_MULTILEVEL () and, together with a specific Arduino program, it works correctly for me; thus, with a single channel, I can control several floor valves; which in my case, there are 2 groups with 8 valves in each group.

Please, Z-wave.me team tell me your opinion on the opportunity to develop these macros.

Sure, we can help you writing Macros and you can even conribute to our Github to make them public (and after we release 7gen you can port them to 7gen too).

But first of all would like to clear a bit the concept of making thermostats in Z-Wave. Both air conditioning and floor heating are considered to be thermostats and not switches. A thermostat is usually made of a mode switch (list of modes + current mode selector) and temperature selector (setpoint for each mode that support a setpoint). So it is not a switch. This was about how Z-Wave presents it.

Additionally there can be a temperature sensor exported to Z-Wave.

As for the peripheral side (how Z-Uno is controlling it) it can of course be a relay. For example: You can introduce a more advanced algo like hysteresis or even a PID. So from Z-Wave point of view you select a thermostat set point, but on the h/w side Z-Uno will turn on/off a releay.

Does it make sense?

Have a look here: https://z-uno.z-wave.me/Reference/ZUNO_THERMOSTAT/

Thank you very much for your answer and I also appreciate the clarification on how Zwave considers the difference between SWITCH and THERMOSTAT. I've been reading the ZUNO_THERMOSTAT () macro and it looks really well designed.

Unfortunately my eedomus device does not recognize all the functionalities of this macro and I have not been able to see or test them in all their funcionality. The message that appears on the eedomus screen is the following: "This peripheral is unknown from the eedomus peripherals base, its functionalities will probably be limited. You can contact the eedomus support communicating the API code of this peripheral so that its integration can be studied". When testing it in my installation: 1) in the MODE channel, no mode has appeared, I can only see the temperature selector and; 2) on the other channel, it seems to me a kind of thermometer.

Despite this limitation, I would like to continue working on the air conditioning issue and, although this macro largely covers what I proposed in my last post, I still think it would be nice to have a new macro (or, perhaps the same ZUNO_THERMOSTAT (), adding a third channel) that would allow controlling the different speeds of the fan coil).

Today I have been studying the Github of Zwave.me to learn how the creation of macros is done, but the only thing related to it found the already known file ZUNO_Definitions.h. Please can you tell me where I can find the information on how to build a macro for ZUNO step by step?

A macro can only consist of supported Z-Uno features and channel definitions. You can check more here:
https://github.com/Z-Wave-Me/Z-Uno-Core ... pport.ucxt
https://github.com/Z-Wave-Me/Z-Uno-Core ... initions.h
https://github.com/Z-Wave-Me/Z-Uno-Core ... Channels.h

Fan can be made like a dimmer (Switch Multilevel)

I have been making an assembly to control floor valves using 7 channels of the type ZUNO_SWITСH_BINARY () one by one and everything has worked correctly.
Later I wanted to improve the program using the possibilities of "ADD CHANNELS" (ZUNO_ADD_CHANNEL (), ...), and when I integrate it into my eedomus, instead of showing 7 SWITCHS, it, inexplicably, appears a TEMPERATURE indicator (only 1 object). I thought it was my mistake, and I have run the program https://github.com/Z-Wave-Me/Z-Uno-Test ... iRelay.ino and the result has been the same: a temperature indicator has been created.
I guess this may also be a problem of the integration between Zwave.me and eedomus. Because I have already encountered other integration problems, about two weeks ago I opened a ticket in eedomus technical support, but they still haven't answered me.
Serguei, please tell me if this problem exists only with eedomus or happens with other controllers as well.
Is there a work plan between zwave.me and eedomus to make the integrations of the (versatile and great) macros that you design? Please, tell me something.
If you see that it is a difficult problem to solve, tell me if it seems reasonable to you that I mount a second controller with zway (or other open software) to avoid these problems of lack of integration?

eedomus relies on templates for devices, so they might not be able to read channels types from the device (as it should be in correct Z-Wave implementation). If eedomus don't answer to the support inquery, probably Z-Way as a secondary controller will be a nice option.

Hello, I think your application can be helpful for my purposes. Today, there is no bigger range of software for synchronizing all devices related to temperature in the house at the IT market. I had a big problem finding a proper solution for my big house to synchronize all conditioners in my house in one system. Hopefully, I found a good air conditioning repair professional service in my area(https://dynamicheatandcool.ca/services/ ... er-repair/). They helped me a lot with setting my conditioner system, but I still didn't synchronize the floor system.