HMLAN disconnected sporadisch

[Guest]

Originally posted by: <email address deleted>

ah - dass war der Kommentar von johank
also die Frage an dich - ist dies das neuste HMLAN?

Seltsam sind die 4 'keep-alive'. Ich werde noch einmal eine Version Basteln
mit Timer-Logs.

Und natuerlich ist der Zeitstempel seltsam.
Kannst du einen groesseren Ausschnitt posten - evtl als anhang? HMLAN hat
in diesem Ausschnitt NICHT neu connected - da sind andere Messages zu sehen

Gruss
Martin


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Die timer sind vieleicht richtig, es kann sein das die nicht im
richtigen reihenfolge im log geschrieben sind. Normalerweise wen es im
200 und mehr ms geht hat mann moeglichewiese dieses problem nicht,

Die aendereung nach 15 is nur proof das ein anders modul dise probleme
verursacht, es ist nicht die loesung. Design rules (<100ms) oder
multithreading. ist die loesung.

Ubrichens, der HMLAN schickt seiene eigene Ack, das kansst du tun
durch ein +A12345,0 wo A12345 die HM device addresse ist zum HMLAN zu
schicken.

 (muss mal checken ob es A12345,0 oder A12345,02,0 ist um den Ack vom
HMLAN abschicken zu lassen.

Die anzahl Acks die HMAN in stock hat sieht man im antwort auf dem K,
leider nicht fuer welche devices. Jedenfalls so habe Ich das
interpretiert.

Ich schicke gar kein Acks ab in mein Basic program..



--Johan


2012/12/19 Martin

> ah - dass war der Kommentar von johank
> also die Frage an dich - ist dies das neuste HMLAN?
>
> Seltsam sind die 4 'keep-alive'. Ich werde noch einmal eine Version
> Basteln mit Timer-Logs.
>
> Und natuerlich ist der Zeitstempel seltsam.
> Kannst du einen groesseren Ausschnitt posten - evtl als anhang? HMLAN hat
> in diesem Ausschnitt NICHT neu connected - da sind andere Messages zu sehen
>
> Gruss
> Martin
>
>
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

In addition to my previous message, I initialize the HMLAN and then send

' setup ACK's for paired units
  rResult = Devices.FindDevicesForInterface(36)
  FOR EACH rResult
  SendHMLAN("+" & rResult!address & ",00,00")
  NEXT

where rResult!address is a pull from a DB giving me the Homematic
deviceaddresses

And everytime a message has been acknowledged by the HMLAN I prepare a new
ACK

IF Sdst = sHMLANid AND bAckRequested = TRUE AND sMsgtype <> "00" AND
sMsgtype <> "3F" AND Left$(sSegments[0], 1) = "E" THEN
    sCmd = "+" & sSrc & ",02,00,"
    SendHMLAN(sCmd)

I'm dealing with the pairing request (00) and the timesync (3F) separate.

--Johan


2012/12/19 Johan van der Kolk

> Die timer sind vieleicht richtig, es kann sein das die nicht im richtigen reihenfolge im log geschrieben sind. Normalerweise wen es im 200 und mehr ms geht hat mann moeglichewiese dieses problem nicht,
>
> Die aendereung nach 15 is nur proof das ein anders modul dise probleme verursacht, es ist nicht die loesung. Design rules (<100ms) oder multithreading. ist die loesung.
>
> Ubrichens, der HMLAN schickt seiene eigene Ack, das kansst du tun durch ein +A12345,0 wo A12345 die HM device addresse ist zum HMLAN zu schicken.
>
>
>  (muss mal checken ob es A12345,0 oder A12345,02,0 ist um den Ack vom HMLAN abschicken zu lassen.
>
> Die anzahl Acks die HMAN in stock hat sieht man im antwort auf dem K, leider nicht fuer welche devices. Jedenfalls so habe Ich das interpretiert.
>
>
> Ich schicke gar kein Acks ab in mein Basic program..
>
>
>
> --Johan
>
>
> 2012/12/19 Martin
>
>> ah - dass war der Kommentar von johank
>> also die Frage an dich - ist dies das neuste HMLAN?
>>
>> Seltsam sind die 4 'keep-alive'. Ich werde noch einmal eine Version
>> Basteln mit Timer-Logs.
>>
>> Und natuerlich ist der Zeitstempel seltsam.
>> Kannst du einen groesseren Ausschnitt posten - evtl als anhang? HMLAN hat
>> in diesem Ausschnitt NICHT neu connected - da sind andere Messages zu sehen
>>
>> Gruss
>> Martin
>>
>>
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Johank

Am Mittwoch, 19. Dezember 2012 18:02:40 UTC+1 schrieb Johank:
>
> Die timer sind vieleicht richtig, es kann sein das die nicht im richtigen reihenfolge im log geschrieben sind. Normalerweise wen es im 200 und mehr ms geht hat mann moeglichewiese dieses problem nicht,
>
> Could be. That is why I need a deeper log. After a disconnect there are
some setup messages that I can find. As those are not present there was no
disconnect to HMLAN.  The connection was not restarted.

> Die aendereung nach 15 is nur proof das ein anders modul dise probleme verursacht, es ist nicht die loesung. Design rules (<100ms) oder multithreading. ist die loesung.
>
> we can see the  delay out of the traces then we can adjust

>
> Ubrichens, der HMLAN schickt seiene eigene Ack, das kansst du tun durch ein +A12345,0 wo A12345 die HM device addresse ist zum HMLAN zu schicken.
>
> I know that the HMLAN sends ACK itself - and waits for ACK as well. It
will repeat messages with a delay of 200ms approx.  I have no idea how to
controll that. Current implementation is that FHEM does not send 'normal'
acks to the device thru HLMAN. It does so for the CUL. I experienced big
confusion when the additional acks are sent. What is sent are 'ack_Status'
if necessary. Those are necessary if FHEM acts as actor.
My recomendation is not to do that but use a virtual device/channel
instead. This gives a cleaner environment.

If you have some information about the meaning of the FHEM-HMLAN protocoll
let me know . There is certainly room for improvement

>  (muss mal checken ob es A12345,0 oder A12345,02,0 ist um den Ack vom HMLAN abschicken zu lassen.
>
> Die anzahl Acks die HMAN in stock hat sieht man im antwort auf dem K, leider nicht fuer welche devices. Jedenfalls so habe Ich das interpretiert.
>
>
> Ich schicke gar kein Acks ab in mein Basic program..
>
> HLMAN also supress simple-ACK. If CUL is used ACKs will pass thru.

Martin

>
>
>
> --Johan
>
>
> 2012/12/19 Martin >
>
>> ah - dass war der Kommentar von johank
>> also die Frage an dich - ist dies das neuste HMLAN?
>>
>> Seltsam sind die 4 'keep-alive'. Ich werde noch einmal eine Version
>> Basteln mit Timer-Logs.
>>
>> Und natuerlich ist der Zeitstempel seltsam.
>> Kannst du einen groesseren Ausschnitt posten - evtl als anhang? HMLAN hat
>> in diesem Ausschnitt NICHT neu connected - da sind andere Messages zu sehen
>>
>> Gruss
>> Martin
>>
>>
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+...@googlegroups.com
>>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Mittwoch, 19. Dezember 2012 18:38:23 UTC+1 schrieb Johank:
>
> In addition to my previous message, I initialize the HMLAN and then send
>
> ' setup ACK's for paired units
>   rResult = Devices.FindDevicesForInterface(36)
>   FOR EACH rResult
>   SendHMLAN("+" & rResult!address & ",00,00")
>   NEXT
>
> where rResult!address is a pull from a DB giving me the Homematic
> deviceaddresses
>
> And everytime a message has been acknowledged by the HMLAN I prepare a new
> ACK
>
> IF Sdst = sHMLANid AND bAckRequested = TRUE AND sMsgtype <> "00" AND
> sMsgtype <> "3F" AND Left$(sSegments[0], 1) = "E" THEN
>     sCmd = "+" & sSrc & ",02,00,"
>     SendHMLAN(sCmd)
>
> I'm dealing with the pairing request (00) and the timesync (3F) separate.
>
> Similar to the current impelmentation in FHEM.
each device that needs to be handles is addded with
+
There is also a command
 -

I assume those are for multi-HMLAN setups and you can use to to controll
which HMLAN has to serve the rspective  device.

I have seen the additional values
+,00,00
also with different values then "00". Do you have an idea or guess about
the meaning of the numbers? It was used whensetting up teh RC12from HMCONFIG

Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

I used Wireshark to analyze the traffic, some parts I did not understand.

For what I can see is that the +hmid,00,00 results in 2 things
1. Acks being sent by the HMLAN
2. The last word in the reply to K increases with the amount of Acks in
stock

The +hmid,02,00 is required to wake up the device.
If I don't send it the device will not reliably return in an awake status
(HM-CC-TC)

My sequence is basically:

1. Send a +hmid,02,00 after the any message that needed to be Acked. (not
after any received message)

2. then when a command needs to be sent to the device, just send it and
don't wait for anything.
Normally the HMLAN provides you with the result of the last sent command.
In this case you will receive a
0008 = NACK from HMLAN. I store the command in the stack.
3. I follow that with a +hmid,02,00
The next time the device reports status, the HMLAN now reports 0081, the
device is awake and ready to accept commands. So the HMLAN prepends data to
the received device message.
4. Then I kick out all commands that I had stored in the stack for that
device in sequence, and clear the sent command from the stack when I
receive the message 0001 (Ack received from remote device) from the HMLAN.

the 0001,0081 and 0008 are the first characters received in the HMLAN
message, before it echoes the timestamps an the actual radio message to the
TCP port
Once I sent out all messages for the device I send -hmid and +hmid. It
seems to clear an internal register in the HMLAN.
This last step is just a result from the Wireshark analysis, but it
apparently needs to be sent to keep the HMLAN happy.


Now, while this works fine for the HM-CC-TC, I have not tested it against
other HM devices.
Unless I choke the interface, this method gives 100% success-rate.

I'll try to send you a log from a few commands if you are interested.
Obviously only the thermostat, that is all I have, and I have not written
any code for other devices.

--Johan


On Wed, Dec 19, 2012 at 8:53 PM, Martin wrote:

>
>
>
> Similar to the current impelmentation in FHEM.
> each device that needs to be handles is addded with
> +
> There is also a command
>  -
>
> I assume those are for multi-HMLAN setups and you can use to to controll
> which HMLAN has to serve the rspective  device.
>
> I have seen the additional values
> +,00,00
> also with different values then "00". Do you have an idea or guess about
> the meaning of the numbers? It was used whensetting up teh RC12from HMCONFIG
>
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

johank,

that is an interresting information.

The detail with + was expected. Interresting is the 02 feature.

For TC I would say this is not necessary. It works fine without. Maybe we
can improve functionallity.
But I will try this with the VD. this does not react adequate if we try to
control it from FHEM.

Regarding the HMLAN status-word reply I have
0000 : message "E" type - message ok for further parsing Not seen with 'R'
type
0001 : send  - ack received
0002 : ?? return our own message?
0008 : no ack received
0021 ?  also something with wakeup?
0081 : => according to you this is the wakeup indication from  - pending
data can be transmitted by now

To control I have
+ # should be send once - then the deivce will be handled by this
HLMAN adapter
- # remote this ID fom LAN adapter - could be used if multiple
adapter are in use.
+,00,00 # I think there is no difference to the first one - seems to
be default
+,02,00 # prepare for wakeup??? have to experiment
+,01,00,F1EF #send from HMconfig to my RC12 once a while during read
- after a certain block.

Others I am not aware off

I don't agree that -hmid +hmid needs to be sent. It works fine without
that.  Some similar procedure was implemented at the time I forst looked at
the code. I came to the conclusion after some testing that this is  not
necessary. All it finally did was to add some delay to the transmission.
You have to obey that many (most?/all?)  HM deviceses need an outage of
~100ms between messages. Sending faster may cause message loss. Second you
have to obey wireless transmission speed of HMLAN. Sending faster then that
will cause the HMLAN to disconnect. I do calculate that briefly out of the
data to be transmitted. I cannot consider concestion on the air interface
nor resend aktions due to missing acks.
I am not sure about the HMLAN buffer for transmitt messages - but it is
very short. You need to queue and delay externally.

Thanks - I will restart testing the VD with your information

Martin


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

One more thing:
After status 0008 I cannot assume that  this is a wakeup device. It also
can be that the device is not present, dead,... it even comes if I
addressed a wron channel.

Therefore I will try to send the 02 prior to the send-message for wakeup
devices.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

> Therefore I will try to send the 02 prior to the send-message for
> wakeup devices.

kann es sein, dass dies auch mein Rauchmelder Problem behebt? Oder hast
du die Hoffnung bei denen schon aufgegeben?

cheers
Martin



Am 20.12.2012 13:44, schrieb Martin:
> One more thing:
> After status 0008 I cannot assume that  this is a wakeup device. It
> also can be that the device is not present, dead,... it even comes if
> I addressed a wron channel.
>
> Therefore I will try to send the 02 prior to the send-message for
> wakeup devices.
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On Thu, Dec 20, 2012 at 1:41 PM, Martin wrote:

> johank,
>
> that is an interresting information.
>
> The detail with + was expected. Interresting is the 02 feature.
>
> For TC I would say this is not necessary. It works fine without. Maybe we
> can improve functionallity.
> But I will try this with the VD. this does not react adequate if we try to
> control it from FHEM.
>

> Regarding the HMLAN status-word reply I have
> 0000 : message "E" type - message ok for further parsing Not seen with 'R'
> type
> 0001 : send  - ack received
> 0002 : ?? return our own message?
> 0008 : no ack received
> 0021 ?  also something with wakeup?
> 0081 : => according to you this is the wakeup indication from  - pending
> data can be transmitted by now
>
>
I have to check, I believe there is also one that means "nice message, but
for another HMLAN)


To control I have
> + # should be send once - then the deivce will be handled by this
> HLMAN adapter
>

the device will always be handled by this HMLAN (pairing), this makes sure
it sends Acks


- # remote this ID fom LAN adapter - could be used if multiple
> adapter are in use.


Don't think so, the messages are also used in a single HMLAN setup.
Additionally, each HM device can only pair with one HMLAN adapter...at
least that is what the third message in the pairing sequence tells me.
But I might be proven wrong, after all there is a dual HMLAN  setup
possible.


> +,00,00 # I think there is no difference to the first one - seems to
> be default
>

I'm sending 00,00 at the init, afterwards only 00,02, and once I'm done
with a device -hmid,+hmid.
Send the 00,00 message and the count at the end of the K reply will go up,
not sure if the same is true for the +hmid message, might well be but in
this case I copied the behaviour of the homematic software.

+,02,00 # prepare for wakeup??? have to experiment
> +,01,00,F1EF #send from HMconfig to my RC12 once a while during read
> - after a certain block.
>
> Others I am not aware off
>
> I don't agree that -hmid +hmid needs to be sent. It works fine without
> that.


 If you start using the 02 feature it might become necessary.

Some similar procedure was implemented at the time I forst looked at the
> code. I came to the conclusion after some testing that this is  not
> necessary. All it finally did was to add some delay to the transmission.
> You have to obey that many (most?/all?)  HM deviceses need an outage of
> ~100ms between messages. Sending faster may cause message loss. Second you
> have to obey wireless transmission speed of HMLAN. Sending faster then that
> will cause the HMLAN to disconnect. I do calculate that briefly out of the
> data to be transmitted. I cannot consider concestion on the air interface
> nor resend aktions due to missing acks.
>

I used actually 350ms between commands. So far I only noted the length of
my command queue to make sure all messages had an ACK. I also requeued
failed commands to give it another try. (and kept a general counter). So
not very sophisticated.
Actually I have 2 queues, a "interface queue" (emptied one message per 350
ms) and a command stack.

In the command stack oldest messages for a device are sent first. Also when
resending failed commands I re-timestamp them.


> I am not sure about the HMLAN buffer for transmit messages - but it is
> very short. You need to queue and delay externally.
>
> I think I wrote registers, not command buffer, the command buffer/queue is
in the software. HMLAN just transmits up to three times the last command,
until it gets an ACK from the device.

Thanks - I will restart testing the VD with your information


If you are brave you can try to set registers in the HMLAN, the D and Y
command will probably do that, with the right code behind it
D1 and D2 will give some info back, again I don't know what, did not make
sense to me.

the B command sets the red light, an puts the HMLAN in a mode in which it
seems to be waiting for something. Power off and on to regain control of
the adapter

Good luck !
Johan

>
> Martin
>
>
>  --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Correct, you should keep track of all messages returning with 0008 status,
and after some amount declare the device dead, or unreachable. If you
re-stack failed commands for a next try, you could count how often a
command for a device was re-stacked, and let that trigger a message. You
could always get the odd radio transmission failure.

--Johan


On Thu, Dec 20, 2012 at 1:44 PM, Martin wrote:

> One more thing:
> After status 0008 I cannot assume that  this is a wakeup device. It also
> can be that the device is not present, dead,... it even comes if I
> addressed a wron channel.
>
> Therefore I will try to send the 02 prior to the send-message for wakeup
> devices.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> kann es sein, dass dies auch mein Rauchmelder Problem behebt?

ich denke nicht. Rauchmelder sind "burst devices" keine "weakup devices".
Ausserdem reagieren sie ja
 

> Oder hast du die Hoffnung bei denen schon aufgegeben?
>
nein, habe ich nicht - habe gerade die referenz-logs gefunden und werden
diese noch einmal durchgehen.

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Donnerstag, 20. Dezember 2012 15:26:07 UTC+1 schrieb Johank:
>
>
>
>
>>
> I have to check, I believe there is also one that means "nice message, but
> for another HMLAN)
>
I don't understand. messages do not destinguish between HMLAN and other  
HMID. So what you mean is that those message could be like monitored events
between two HM devices? I will watch

>
>
> To control I have
>> + # should be send once - then the deivce will be handled by this
>> HLMAN adapter
>>
>  
> the device will always be handled by this HMLAN (pairing), this makes sure
> it sends Acks
>
> - # remote this ID fom LAN adapter - could be used if multiple
>> adapter are in use.  
>
>  
> Don't think so, the messages are also used in a single HMLAN setup.
> Additionally, each HM device can only pair with one HMLAN adapter...at
> least that is what the third message in the pairing sequence tells me.
> But I might be proven wrong, after all there is a dual HMLAN  setup
> possible.
>

I consider an environment with 2 HMLAN both having the same ID. Someone
with a remote walking thru the house wants to use the closest HMLAN. I
would assume eq3 has a mechanism in place to support that. This would mean
that you can switch off sending to a HMID unless it is put on your list.
Receive should always be possible  in order to determin the RSSI for best
transmission. Even though I am not sure how it works I would be disapointed
if this is not forseen by a protocoll of that complexity .

 
>
>> +,00,00 # I think there is no difference to the first one - seems
>> to be default
>>
>  
> I'm sending 00,00 at the init, afterwards only 00,02, and once I'm done
> with a device -hmid,+hmid.
> Send the 00,00 message and the count at the end of the K reply will go up,
> not sure if the same is true for the +hmid message, might well be but in
> this case I copied the behaviour of the homematic software.
>
> +,02,00 # prepare for wakeup??? have to experiment
>> +,01,00,F1EF #send from HMconfig to my RC12 once a while during
>> read - after a certain block.
>>
>> Others I am not aware off
>>
>> I don't agree that -hmid +hmid needs to be sent. It works fine without
>> that.  
>
>
>  If you start using the 02 feature it might become necessary.
>
will see. You mentioned both 00,02 and 02,00. Is this a type?

>
> Some similar procedure was implemented at the time I forst looked at the
>> code. I came to the conclusion after some testing that this is  not
>> necessary. All it finally did was to add some delay to the transmission.
>> You have to obey that many (most?/all?)  HM deviceses need an outage of
>> ~100ms between messages. Sending faster may cause message loss. Second you
>> have to obey wireless transmission speed of HMLAN. Sending faster then that
>> will cause the HMLAN to disconnect. I do calculate that briefly out of the
>> data to be transmitted. I cannot consider concestion on the air interface
>> nor resend aktions due to missing acks.
>>
>
> I used actually 350ms between commands. So far I only noted the length of
> my command queue to make sure all messages had an ACK. I also requeued
> failed commands to give it another try. (and kept a general counter). So
> not very sophisticated.
> Actually I have 2 queues, a "interface queue" (emptied one message per 350
> ms) and a command stack.
>
350ms is to long I think. The window for wakeup devices is like 200ms
(without 02...) Waiting 350 will certainly be too late - we tried that.
I had not issue with 100ms on a device level. HMLAN can do more - but I am
not sure about the actual restrictions - e.g. how many pending acks in
parallel.

>
> In the command stack oldest messages for a device are sent first. Also
> when resending failed commands I re-timestamp them.
>
this is a deep field. e.g. setting parameter in the device is a sequence of
at least 3 messages. If one is lost you would have to resent starting with
the first one. I have not jet implemented this complexity. Also I added
some timer in the device-layer. Thus the correct procedure in my
architecture would be to queue only on device level, not on IO-level.
Resend need to  consider device-type. a resend for a weakup device needs to
be delayed untill next weakup (not jet impelmented)
My current resent is pretty stupid and does not obey those things. At some
time I intend to consider device-type and command level (multi-message
commands)  - but first I will try to weakup a device with the inforamtion
from you

>  
>
>> I am not sure about the HMLAN buffer for transmit messages - but it is
>> very short. You need to queue and delay externally.
>>
>> I think I wrote registers, not command buffer, the command buffer/queue
> is in the software. HMLAN just transmits up to three times the last
> command, until it gets an ACK from the device.
>
agree. I think it was able to handle more then one message during testing.
But  this is insecure and hard to handle.

>
> Thanks - I will restart testing the VD with your information
>
>
> If you are brave you can try to set registers in the HMLAN, the D and Y
> command will probably do that, with the right code behind it
> D1 and D2 will give some info back, again I don't know what, did not make
> sense to me.
>
> the B command sets the red light, an puts the HMLAN in a mode in which it
> seems to be waiting for something. Power off and on to regain control of
> the adapter
>
> Good luck !
>

Thanks
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On Thu, Dec 20, 2012 at 5:03 PM, Martin wrote:

>
>
> Am Donnerstag, 20. Dezember 2012 15:26:07 UTC+1 schrieb Johank:
>
>>
>>
>>
>>>
>> I have to check, I believe there is also one that means "nice message,
>> but for another HMLAN)
>>
> I don't understand. messages do not destinguish between HMLAN and other
> HMID. So what you mean is that those message could be like monitored events
> between two HM devices? I will watch
>

HMLAN monitors all traffic, I have 2 and can see all messages on the one
that is not paired with anything.


>
>
> I consider an environment with 2 HMLAN both having the same ID.
>

Agree in that scenario

>
>>
>>
>>
>>
> will see. You mentioned both 00,02 and 02,00. Is this a type?
>

is typo

>
>>
>> 350ms is to long I think. The window for wakeup devices is like 200ms
> (without 02...) Waiting 350 will certainly be too late - we tried that.
>
I'm not delaying the first message, only the subsequent ones. And the TCP
socket implementation is not so robust in Gambas, I may have choked
something else before the adapter. At least I could send over 20 messages
to the same device after it woke up, so I was happy


>
> this is a deep field. e.g. setting parameter in the device is a sequence
> of at least 3 messages.
>
Same problem encountered for pairing yes, I worked around that by not
sending the next one before I have a successful previous msg.
Looks like a layered approach is required, time the messages going out,
sequence the command messages, do errorchecking, report errors and let the
layer(s) above that take care of the errors.

>
>>
> Johan
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Von FHEM wiki, Request for Proposals
 start quote:
Mechanismus fuer langsame Readings

*Problemstellung*: Laengere Verarbeitungsprozesse in einzelnen Modulen
(z.B. aufgrund von Netzwerklatenzen oder toten Geraeten) halten fhem
komplett an und verhindern die Verarbeitung von Events.

*Loesung*: Multiprocessing

Beim Multiprocessing wird der fhem-Prozess geforkt, wenn ein Reading vom
Geraet eingelesen werden soll. Der Vaterprozess wird sofort fortgesetzt und
erledigt weitere Aufgaben. Der Kindprozess holt die Readings vom Geraet,
liefert sie an den Vaterprozess und verendet.

Die Lieferung an den Vaterprozess erfolgt durch eine Verbindung zu fhem via
Netzwerk und Aufruf des Befehls

ende quote


--Johan


On Thu, Dec 20, 2012 at 7:43 PM, Johan van der Kolk <
johan.vanderkolk@gmail.com> wrote:

>
>
> On Thu, Dec 20, 2012 at 5:03 PM, Martin wrote:
>
>>
>>
>> Am Donnerstag, 20. Dezember 2012 15:26:07 UTC+1 schrieb Johank:
>>
>>>
>>>
>>>
>>>>
>>> I have to check, I believe there is also one that means "nice message,
>>> but for another HMLAN)
>>>
>> I don't understand. messages do not destinguish between HMLAN and other
>> HMID. So what you mean is that those message could be like monitored events
>> between two HM devices? I will watch
>>
>
> HMLAN monitors all traffic, I have 2 and can see all messages on the one
> that is not paired with anything.
>
>
>>
>>
>> I consider an environment with 2 HMLAN both having the same ID.
>>
>
> Agree in that scenario
>
>>
>>>
>>>
>>>
>>>
>> will see. You mentioned both 00,02 and 02,00. Is this a type?
>>
>
> is typo
>
>>
>>>
>>> 350ms is to long I think. The window for wakeup devices is like 200ms
>> (without 02...) Waiting 350 will certainly be too late - we tried that.
>>
> I'm not delaying the first message, only the subsequent ones. And the TCP
> socket implementation is not so robust in Gambas, I may have choked
> something else before the adapter. At least I could send over 20 messages
> to the same device after it woke up, so I was happy
>
>
>>
>> this is a deep field. e.g. setting parameter in the device is a sequence
>> of at least 3 messages.
>>
> Same problem encountered for pairing yes, I worked around that by not
> sending the next one before I have a successful previous msg.
> Looks like a layered approach is required, time the messages going out,
> sequence the command messages, do errorchecking, report errors and let the
> layer(s) above that take care of the errors.
>
>>
>>>
>> Johan
>>
>>  --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com