Commands per hour

Hi,

my understanding is that FHZ1300PC can send only a specific number of commands per time period.
If so, how many commands can FHZ1300PC send in what time period and what happens when this number is exceeded - when/how it recovers? Can this recovery be controlled from IP-Symcon (= can the counter be reset from IP Symcon)?

The duty cycle is ≤0,1% per one hour.
IPS can´t reset this per software. It is a hardware specification.

So it can broadcast only for 3,6 seconds / hour?

Next think I do not know is how long one command takes.
Any advice here?

So I found the following information (which contradicts 0,1% limit). The sources are not confirmed.

The duty cycle of FS20 is 1%.
ON bit of FS20 takes 1,2ms, OFF bit 0,8ms
One FS20 command has 4 or 5 bytes.
A device repeats command 3 times when sending.
FS20 device sends up to 160 commands per hour. I do not know exactly how this number was reached. Plain 40 bits per command and 1% gives 250 commands. Probably extra bits in packet (parity? stop bits?).
In any case, 160 commands per hour is supported by the 24 seconds interval in FS20 senders - 3600/24 = 150 commands per hour.

So here is the information about number of commands which can be sent via FS20 sender (from FHZ forum):

Länge eines Datentelegramms: 40 oder 48 Bit plus 12 „0“-Bit, ein „1“ Bit zur Synchronisation, ein „0“-Bit für EOT ==> 48 Bit annehmen für Berechnung plus 14,45 Millisekunden für Synchronisation
Dauer eines „1“-Bit: zwischen 1000 und 1450 Mikrosekunden (ein „0“-Bit ist immer kürzer) >> 1450 Mikrosekunden annehmen für Berechnung

Daraus folgt die „Berechnung“:
48 Bit * 1450 Millisekunden + 14,45 MIllisekunden sync == 84,05 Millisekunden pro Datentelegramm
Jeder Befehl wird drei mal mit jeweils 10 ms Pause gesendet == 84,05 ms * 3 + 30ms == 282,15 ms pro Befehl
Anzahl Befehle auf dem Kanal == 1/282,15e-3 == 3.544 pro Sekunde

Anzahl der Befehle pro Stunde== 3,544 * 3600 == 12759

Bei Einhaltung der Sendebegrenzung von 1 Prozent == 127 Befehle pro Sender

So the „worst-case“ scenario when we send only „1“ bits would allow for 127 commands per hour.

In homeputer studio, there is a command „zeitkontoreset“ which can reset the 1% counter (it can be executed once per 90 minutes).
Is there similar command in ip-symcon?

Hi Marian,
there is no function in IPS to reset the counter. I think normaly it is not allowed to do this.

Best regards
Klaus

Well, HW supports that (according to people from FHZ forum), with the limit of 1x per 90 minutes.

Also, it is not completely clear to me whether it is possible to get the status of the „counter“ from the hardware. Homeputer Studio doesn’t allow that, but one source on the internet mentioned that HW supports such command. It would be a nice feature in IP-SymCon :wink:
Applications would at least know that the commands will not get through.

afik is it resetted by hardware every hour. What need could be there to reset it by software every 90 minutes? :confused:

PLUS: IPS is not FS20-Software. If you need more power than FS20 can provide you, you should add some moeller, z-wave or enOcean components. Even a second FHZ if you’d think that’ll be clever.

Toni

Of course it should not be reset automatically by IP-Symcon.
However, it could be used as an „emergency measure“ if you run close to the limit. It would increase the throughput of FHZ1xxxPC.

E.g. I run a kind of re-initialization at night, to recover from problems which could occur (server PC being rebooted, transmissions not received, etc). So I send more commands together. Reset afterwards could be useful.

I agree that „reset“ feature is really only a nice-to-have, but getting the information about the counter status would be beneficial.
It would increase the reliability of the software as at the moment user has no way of finding out that the commands will be lost due to the limit.

As about adding other components… yes, that’s of course possible.
However, it adds to the cost significantly.
So I prefer to use FS20 to the limit and add other components only if/when FS20 is not up to the task.

We are not aware of the possibility to read the current percentage of messages that are left for this hour. Therefore we are not able to implement this feature. (If you have any protocol level details you are free to send me a PM)

paresy