What would you like me to check?
My network now seems to be 100% reliable and the ModemDB download time under Openhab seems to match what I see under insteonterminal.
When I run the download under insteonterminal, i don’t see any output until it completes, then the whole DB is listed at once.
If the speed with insteon terminal is the same, then I can’t come up with anything reasonable explanation as to why it should be so slow. In insteonterminal you can simply hack a print statement somewhere into the python code that tells you whenever a new line of the modem database comes in. At least that would tell us if it stalls occasionally or if the messages come in at regular intervals. If they do, at what frequency do messages arrive?
I modified the modem DB builder python code to print the records as they come in.
They arrive right around once per second, at a very consistent rate. Since it produces a total of 124 records, that takes just over 2 minutes to complete.
Thanks, that was very helpful!
This means that it’s pulling one record per tcp poll, which happens at 1sec interval. I had thought it would pull multiple records, but not so.
Now how to fix it? We should really only bump the timeout for the hub2. PLM and hub download much faster.
Probably the best would be to have something like “estimated_number_of_devices” in the config file, and then have the binding calculate the timeout from there.
@Bernd_Pfrommer, what if the code for building the database is refactored from an overall timeout for all the link records to a timeout per link record request?
As an experiment, I tried changing the timeout value for insteon-terminal in init.py.
The optimal value for my system seems to be around 250 mS. More than than just slows it down and less results in more retries, also slowing it down.
At 250 mS, the time to load the DB goes down from 125 seconds or so to 37 seconds.
I verified the same change works in the insteonplm binding (poll_time=250 in the init file) and time to download the database goes down to 33 seconds.
Duh, that seems like the best idea. Wonder how much work that is to do. I’m more afraid of the testing actually, since I don’t have an old hub. And it was for the old hub that we put this in from what I remember.
My insteon system has been working well for the last couple of weeks.
I do get the following warning message in my log file several times per day:
15:23:05.622 [WARN ] [steonplm.internal.message.MsgFactory] - unknown command code/ext flag: 0x42
15:23:05.624 [WARN ] [ding.insteonplm.internal.driver.Port] - bad data received: unknown command code/ext flag: 0x42
Is this normal? Does it happen with a real PLM (instead of a hub2)? It’s always with the 0x42 value.
I also occasionally get the following, but I assume that’s normal for the insteon binding:
15:01:14.354 [WARN ] [steonplm.internal.message.MsgFactory] - incoming message does not start with 0x02
15:01:14.356 [WARN ] [ding.insteonplm.internal.driver.Port] - bad data received: incoming message does not start with 0x0 2
15:01:14.358 [WARN ] [ding.insteonplm.internal.driver.Port] - got bad data back, must assume message was acked.
That’s a property of 2014 hub. What’s your poll interval set to? Did you put that back to 1000ms?
Ok. Thanks.
I’m still using the 250mS poll interval and that seems rock solid. The database downloads nearly 4X as fast.
That could be one of the reasons why you are getting the corrupt messages. I suspect what happens is that the binding polls the hub while only half the message has made it from the PLM modem into the hub’s internal buffer. The more frequently you poll, the more likely you get corrupt data messages.
Bernd