HomeMatic CCU2 bei ELV bestellen

FHZ 1300 Sende Begrenzung - in English

FHZ 1000, FHZ 1000 PC, FHZ 1000 FW, FHZ 1300 PC, FHZ 1300 PC WLan, FHZ 1350 PC, FHZ 2000 etc.

Werbung


Re: FHZ 1300 Sende Begrenzung - in English

Beitragvon fsommer1968 » 23.02.2010, 15:40

marian hat geschrieben:Additional question...
The time slot counter is floating (time spent over last hour) or there is a reset every hour?
Marian

The time slot counter should be floating.

I would not take the number of theoretical allowed time slots into account. Keep in mind that the protocol used does not handle collisions. As more datagrams are sent the probability of collisions of all of your senders and possible data loss increases. Therefore keep the number of datagrams as low as possible, to ensure, that there will be less collisions.
fsommer1968
 
Beiträge: 133
Registriert: 16.02.2008, 18:05

Re: FHZ 1300 Sende Begrenzung - in English

Beitragvon marian » 23.02.2010, 15:56

Thnks.

In general, I keep them low.
However, as you write, commands sometimes don't get through and there's no way of knowing.
It's annoying in some cases (e.g. when turning the light on fails).

Therefore my idea is to have a floating counter of commands sent over last hour and if the number is small (so I have enough time slots available), to repeat some commands with random delay.
I should note that I use PC & FHZ1300PC heavily, as I include the logic of the type "if it is a daytime for children", etc.
marian
 
Beiträge: 11
Registriert: 08.01.2010, 14:50

Re: FHZ 1300 Sende Begrenzung - in English

Beitragvon fsommer1968 » 23.02.2010, 18:27

marian hat geschrieben:Thnks.
It's annoying in some cases (e.g. when turning the light on fails).


Most of the people in this forum will agree with your findings.
Managing the time slot account and using remaining time slots for resend operations is an interesting approach, but do you have so much actors in place that that the amount of remaining time slots is really an issue ?

A best practice is to send every command two or three times. That is also my approach as long as the actor can deal with multiple commands (lights) with a delay of two seconds (i have a fs20 RPT therefore i need a delay of at least 1,45 seconds). If possible use the timer function of the fs 20 actor. It may save a lot of send commands, but of course it´s not always possible.
fsommer1968
 
Beiträge: 133
Registriert: 16.02.2008, 18:05

Re: FHZ 1300 Sende Begrenzung - in English

Beitragvon marian » 23.02.2010, 19:18

No, I do not have so many actors yet. I didn't know about the limit and I've run into it only because of a bad design.
But as the number of actors will eventually increase, I'm trying to devise an approach that will work also in future.
It's easier to reprogram few actors now than many later :)

As of now, if there are over 50% time slots available, I'm sending ON commands with random delay of 300-1000ms between 1st and 2nd command and 1000-3000ms between 2nd and 3rd.
I send only 2 OFF commands (delay of 10-20seconds), with SwitchDuration serving as a safety net.
I will see how it works...
marian
 
Beiträge: 11
Registriert: 08.01.2010, 14:50

Re: FHZ 1300 Sende Begrenzung - in English

Beitragvon jwka » 15.05.2010, 00:10

Well, also in the IP Symcon forum, the limit (duty cycle) was discussed, some time ago (http://www.ip-symcon.de/forum/f18/fhz1300-haengt-7986), triggered by a hang of the FHZ detected by some users (including me).

I did some intensive research on that issue early 2009 when doing range-tests in my house and considering to use FHZ as a repeater for each and every telegram sent to be save from droputs. To get an idea of what to do and where my critical areas were, I first had FHZ sent a telegram again and again moving around with some receivers. Here I detected the problem:

When sending every 2 seconds (initally 1 second but that lead into a system fail quite soon) it failed after somewhat 50 Minutes or so. Reducing it to one telegram each 3 seconds, I did not encounter problems and was able to make range test for some hours.

I asked the ELV technicians and after insisting with my empirical results that their first answer could not be really true (they told me that 40 to 50 telegrams per hour should be a limit), I got the answer that one telegram in sum will occupy some 20-30 ms of time.

Since they need to adress the 1% (limit in total occupation time per sender, there should be roughly 36 seconds of occupied time per sender (which FHZ is) which means, 36.000 ms of sending time per hous. Using the 30ms, per telegram, you will end up with 1.200 per hour which drills down to one telegram every 3 seconds, using 20ms you will end up with one every 2 seconds, which comes quite close to my empirical values.

What I did in the end was to have one global script (IP Symcon) that repeats all telegrams that are critical where I simply add any adress to a list of "to be repeated ones" that had any problems in real life conditions. This in deed limits the ones to be repeated to somewhat 30 - 70% depending on installations and meanwhile, my system is quite reliable!

Since we sometimes have terribly often power outages (up to 30 times a day in heavy rain/wind periods) that result in out of sync situations between reality of the receivers and status in the software, I do repeat any "on" status after power-on that is detected by a TFK. Additionally, at 4:00am I have a "reset" of all devices to be switched off (because that is the reality in 99,99% of all days a year - apart from birthday and other parties.

Regards
jwka
FS20-System: FHZ Lan & IP-Symcon, ca. 25 Aktoren, 20 Sensoren, alle Handsender, diverse Eigen- und Umbauten
Anbindung an Squeezeserver, Twonky und TVersity sowie Übergang zu EIB steht aus.
jwka
 
Beiträge: 97
Registriert: 20.10.2008, 13:06
Wohnort: Deutschland & Spanien

Nächste

Zurück zu ELV FHZ Funk-Hauszentralen

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste







© homematic-forum.de & Lizenzgebern. Alle Rechte vorbehalten. Alle Bilder & Texte auf dieser Seite sind Eigentum
der jeweiligen Besitzer und dürfen ohne deren Einwilligung weder kopiert noch sonstwie weiter verwendet werden.