What's the meaning of the duty cycle value?

Tags: #<Tag:0x00007f6174178130> #<Tag:0x00007f6174178040>

While playing with some MAX! devices, I wonder what the duty cycle value actually means?

I know the principle of duty cycles, and I understand that devices are allowed to send only during 1% of the time (or 36 seconds per hour). However, I don’t understand how this correlates with the value in the MAX! binding. The docs say “Duty cycle indicates how much of the available time is consumed” – but it stays a mistery to me how it is indicated. In seconds? In 0.01 percent? Or in percent of the 1%? I see messages like

2018-12-08 00:19:52.271 [vent.ItemStateChangedEvent] - MAXCubeLANGateway_DutyCycle changed from 85 to 88

which makes me think it will stop at 100, but I am not sure. I’d love to update the docs to be a bit more specific about that. Is my guessing correct?

Thanks

I’d love to but I don’t think anyone will be able to confirm or deny that guess of yours.
It’s inner workings of the eQ-3 MAX! system that noone outside of eQ-3 knows of for sure, and they’re a totally user unfriendly company in not disclosing any information at all to users, let alone to developers (all of the max binding already has only been been possible to build by means of reverse engineering) .

After some research and trying things out, I’m quite confident that my assumptions are either correct or a usable model of what the value from the MAX! Cube means. In my opinion, for users of the binding, it’s would be more helpful, if we add these findings to the docs than to leave the meaning completely open there.

By all means please do so. For something like this you are in a better position to add the content to the docs than anyone else.

Okay, will do!

A few more things I#d like to ask in this context:

I noticed that when changing the set temperature using the default widget in BasicUI (the one with the up and down buttons), for example, changing the temperature from 20.0 to 21.5 by tapping up three times leads to 3 update commands being sent to the device. To avoid unnecessary consumption of the duty cycle, it would make sense to have a tiny delay while waiting for additional changes from the UI before sending out the final new value.

I was thinking about doing this by defining some proxy item, but then I thought this should actually be part of the binding. I don’t think that I’m the first one coming up with this idea, so – have I overlooked something?

@rlkoshak: Your design patterns are absolutely great! However, I did not find the Design Pattern: Gate Keeper tutorial at first, because I was searching for “duty cycle”, but your tutorial does not mention this term, so it did not show up in the search results. I’d propose that you mention the usefulness of the design pattern with regards to the duty cycle problem in you article. You do mention Insteon and 433MHz, but to improve search results, I think you should other technologies like MAX!, Homematic, Intertechno and 868 MHz and, of course, the term duty cycle.

However, re-reading your article, I’m not sure any more that it actually addresses the duty cycle problem…

As far as I know, the Max binding is the only one that users that term. I don’t use this binding so there is no way I would have it could have known to or that term into the DP. And it really isn’t feasible to search through all 350+ bindings to make sure that everyone’s specific terminology are included in every dp.

Honestly, this post is the first I’ve seen this term used in the forum and I’ve no really good concept of what it really means.

The gatekeeper do is to prevent oh from overloading some device by sending commands too close together, but all commands eventually get sent. What you are describing with the setpoint is a different problem.

Honestly, this post is the first I’ve seen this term used in the forum and I’ve no really good concept of what it really means.

I wonder why? In Wikipedia, the duty cycle (aka power cycle) is explained as " is the fraction of one period in which a signal or system is active". It is a common term, and AFAIK the 1% limitation applies to all devices signaling on 434 and 868 MHz, including MAX!, Homematic, Intertechno, but also Z-Wave and probably Zigbee.

Yes, the gatekeeper is not the right design pattern. What I probably need is a proxy item that delays sending the command for a half a second or so, waiting for more changes during that time and if so, sending only the last value. Will post when I’ve got it together.

I can’t speak to the rest but I can say that I can send commands to zwave as fast as I want and all the devices perform the commanded action within milliseconds of each other. For example, if I send a command to my Lights group which is all zwave, 8 on commands get sent to the binding and all 8 turn on at the same time as far as is humanly perceived. If there is a sorry cycle it isn’t human perceivable.

I believe the same goes for zigbee but don’t have personal experience to confirm that. I have no experience with Honematic or Intertechno so I can’t say. But I can say that in the 100k+ posts on this forum the term appears in 32 postings, including this thread. And about 3/4 of those are referring to Max.

The duty cycle does not lead to delays in a scenario like the one you describe. Devices can send commands or status info with no delays at all as long as the duty cycle is not used up. Only then, the devices must stop sending for a while.

Note also that the exact specifications of Z-Wave depend on the country or area of the world. For example, while in Europe the 868 MHz frequency band is used, in the USA it’s the 900 MHz frequency band. And while in Europe there is the said 1% limitation, there seems to be no such limitation in other areas of the world, so that might be the reason why you never experienced any problems to duty cycles with Z-Wave.

But the fact remains that the term “duty cycle” is not one that is used much outside of Max among the 350+ OH bindings.

I’m not sure, but from I what I’ve found and assume to have have understood, it seems like Z-Wave handles the limitations in a more sophisticated way by being able to bundle multiple commands in one transmission. However, you’re definitely right when you say that it’s not frequently mentioned as an issue. The very few mentions I’ve found were on German sites.