database incomplete, reload() and retry! #7

integrul · 2016-03-19T00:35:19Z

Hello I have the same issue as PhilippeLibioulle commented on Feb 11

When I try to add / remove any entry to the db for the thermostat I get the error " database incomplete, reload() and retry!" . I checked in my linkdb.py and it contains the row 162 with... if lastVal != self.topOfDatabase: Therefore I believe I am running the latest version.

Is there any condition that would cause the ThermostatDBBuilder not to get called and may be attempting to add these entries as a standard device ( 0x0fff ) I am using Insteon HUB 2014 (2245-222) I believe that testing was completed using 2413S PLM not sure if that would be any different.

I have all other commands working including adding / removing entry to the modem database so I am confident that I have the correct syntax. I am using the instructions provided here -->>
https://github.com/pfrommerd/insteon-terminal/blob/master/README.md

Many thanks in advance.
Michael

pfrommerd · 2016-03-19T02:17:04Z

Do you get the "database incomplete" message every time you try to add/remove an entry, or is it only sometimes? At times the insteon network + the hub can be rather unstable and drop messages. Also, do you see any 'warn' log messages in the console output which could be indicative of message drops? A text snippet of the result you get from running the command would also be very useful in debugging the problem.

pfrommerd · 2016-03-19T02:17:52Z

Note that you can switch on debug logging via: setLogLevel("DEBUG")

integrul · 2016-03-19T02:35:34Z

Hello, I did some more research. For example I changed the code so that any variant of DBBuilder would use 0x1fff this was a crude way of checking if perhaps it was using a different DBBuilder however the comments that this bug occurred mainly because all other devices are 0x0fff got me thinking more in depth because I Am actually using a 2441V which is the insteon adapter for Venstar Thermostats. I was able to control the thermostat from the command line, that's why I thought it was behaving the same as the 2441TH - but further testing revealed that this is a hybrid device. I modified the code so that the ThermostatDBBuilder used 0x0fff because I thought perhaps the database performs more like a standard device than a thermostat. And this appears to have worked.

But all of the register locations and codes appear to be the same as the 2441TH, being that this insteon adapter is *_not *_made by Venstar but made by the same company that makes the 2441TH thermostat.

I am doing further testing and I will report back. But in this case it looks like a new device type may have to be added which is 2441V and if that is the case, the ThermostatDBBuilder may then have to check thermostat type.

I have not ruled out unstable insteon network, however at this stage I did get this error 100% of the time when attempting to manipulate the database of the thermostat. It's the only insteon device I have so I was not able to test any other device for integrity of the insteon network. I will also enable debug logging.

Thank you again for the assistance, I will report back my findings.

integrul · 2016-03-19T16:26:37Z

Hello, Do you have any idea why linkData1 = 0x00 during the add controller instruction.

MY MODEM

modem.addController("14.B9.48",00)
sent msg: OUT:Cmd:0x6F|controlCode:0x40|recordFlags:0xA2|ALLLinkGroup:0x00|linkAddress:14.B9.48|linkData1:0x00|linkData2:0x00|linkData3:0x00|
addController got msg: IN:Cmd:0x6F|controlCode:0x40|recordFlags:0xA2|ALLLinkGroup:0x00|linkAddress:14.B9.48|linkData1:0x00|linkData2:0x00 |linkData3:0x00|ACK/NACK:0x15|

modem.getdb()
0000 kitchen_thermostat 14.B9.48 CTRL 11100010 group: 00 data: 00 00 00
Modem Link DB complete

According to the instructions the group data = 01 00 00

EXAMPLE MODEM
And the modem db should look like that:

modem.getdb()
0000 thermostat 32.F4.22 RESP 10100010 group: 01 data: 00 00 01
0000 thermostat 32.F4.22 RESP 10100010 group: 02 data: 00 00 02
0000 thermostat 32.F4.22 RESP 10100010 group: 03 data: 00 00 03
0000 thermostat 32.F4.22 RESP 10100010 group: 04 data: 00 00 04
0000 thermostat 32.F4.22 RESP 10100010 group: 05 data: 00 00 05
0000 thermostat 32.F4.22 RESP 10100010 group: ef data: 00 00 ef
0000 thermostat 32.F4.22 CTRL 11100010 group: 00 data: 01 00 00
Modem Link DB complete

Do you think this could be causing a problem when used with openHAB

Thanks!

pfrommerd · 2016-03-20T03:10:47Z

The openhab binding does not look at the link data. In most devices, the link data is used to store the device type of the other device (the first two bytes) and the group on which the other device has been linked (the last byte). Originally, the openhab binding used the first two bytes to do type checking for devices, but that feature was removed as it was discovered that, in many situations, the link data was either corrupted or had been zeroed out. At the moment, openhab only checks the database to make sure that all devices are actually linked to the modem, but does not use the link data.

In short, the linkData1 being 0x00 shouldn't affect openhab and isn't an issue as the link data isn't being used (nor should it be, given its unreliability).

integrul · 2016-03-20T03:21:52Z

So If I have the following items - is there any fundamental setup step I have missed in my setup below:

*.cfg
insteonplm:port_0=/hub2/Westmins:gBdk53xy@192.168.83.123:25105,poll_time=1000

*.items
Number thermostatCoolPoint "cool point [%.1f °F]" { insteonplm="14.B9.48:F00.00.18#coolsetpoint" }
Number thermostatHeatPoint "heat point [%.1f °F]" { insteonplm="14.B9.48:F00.00.18#heatsetpoint" }
Number thermostatSystemMode "system mode [%d]" { insteonplm="14.B9.48:F00.00.18#systemmode" }
Number thermostatFanMode "fan mode [%d]" { insteonplm="14.B9.48:F00.00.18#fanmode" }
Number thermostatIsHeating "is heating [%d]" { insteonplm="14.B9.48:F00.00.18#isheating"}
Number thermostatIsCooling "is cooling [%d]" { insteonplm="14.B9.48:F00.00.18#iscooling"}
Number thermostatTempFahren "temperature [%.1f °F]" { insteonplm="14.B9.48:F00.00.18#tempfahrenheit" }
Number thermostatTempCelsius "temperature [%.1f °C]" { insteonplm="14.B9.48:F00.00.18#tempcelsius" }
Number thermostatHumidity "humidity [%.0f %%]" { insteonplm="14.B9.48:F00.00.18#humidity" }

*links:

Terminal ready!

modem.getdb()
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: 01 data: 00 00 01
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: 02 data: 00 00 02
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: 03 data: 00 00 03
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: 04 data: 00 00 04
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: 05 data: 00 00 05
0000 kitchen_thermostat 14.B9.48 RESP 10100010 group: ef data: 00 00 ef
0000 kitchen_thermostat 14.B9.48 CTRL 11100010 group: 00 data: 00 00 00
Modem Link DB complete
th.getdb()
getting db, be patient!
sent db query msg, incoming records: >>> 1 2 3 4 5 6 7 8
----- database -------
0fff test_modem 31.46.7B CTRL 11100010 group: ef data: 03 1f ef
0ff7 test_modem 31.46.7B RESP 10100010 group: 00 data: 00 00 00
0fef test_modem 31.46.7B CTRL 11100010 group: 01 data: 00 00 01
0fe7 test_modem 31.46.7B CTRL 11100010 group: 02 data: 00 00 02
0fdf test_modem 31.46.7B CTRL 11100010 group: 03 data: 00 00 03
0fd7 test_modem 31.46.7B CTRL 11100010 group: 04 data: 00 00 04
0fcf test_modem 31.46.7B CTRL 11100010 group: 05 data: 00 00 05
0fc7 00.00.00 00.00.00 (RESP) 00000000 group: 00 data: 00 00 00
----- end ------------

Is there anything I missed to configure this? Is there any reason why I could be getting:

2016-03-04 09:23:00 WARN o.o.b.i.InsteonPLMActiveBinding[:485]- device 14.B9.48 not found in the modem database. Did you forget to link?

Thanks again for your guidance.
Michael

integrul · 2016-03-21T01:14:17Z

I have the system working, I can confirm that the DB entries for the 2441V do use 0x0fff, I had an issue with my openHAB config as a result the insteon binding was not working correctly. I noticed that the data does not get initialized and only gets sent from the thermostat once changed. This results in empty fields until the thermostat values change. Is there any way to force the thermostat to send the data upon initialization in order to set all the values to the correct values prior to the value changing?

berndpfrommer · 2016-03-21T01:57:43Z

I just pushed a new device in the 2441V thermostat. The only difference to the 2441TH is the top of database flag. If you have time to test and see if you can load the database that would be great.

Not sure what you mean with "send upon initialization". Initialization of openhab? Or the thermostat? Some data is actively being polled for by the binding (as a matter of fact, I think all of it). So you should get correct values once the first poll happens (I have my poll interval set to 10min), not have to wait for some change to happen. And openhab should not send you any values (unless you persist them) until the first valid data comes in. Then there is also the out-of-band sending of messages by the thermostat. That only happens when the settings (or e.g. temperature) changes.

So check your insteonplm debugging log to see what the thermostat answers back when it's being polled. If it doesn't reply, something is wrong. Your link database seems fine though at first glance, the thermostat should answer. You can check what command code the binding sends out to query (I think cmd1=0x2e, cmd2=0x00 and 0x02). You can try sending those out via insteon terminal (th.getData1(), th.getData1b(), th.getData2()) and see what comes back.

integrul · 2016-03-21T02:39:45Z

I will definitely test the new device 2441V and report back the results of my testing. Thank you for your support on this matter.

With regards to the initialization, all of the values in openhab are null, I have set my polling interval to 100 seconds ( I only have 1 insteon device) just to test. And there is simply null values in the user interface until I change them. Example - Increment the heat setpoint from the openhab ui then the heat setpoint a) updates on the thermostat to the revised value b) shows corretly in the openhab ui. Similar, if I increment the heat set point on the physical thermostat it then changes from null to the correct value in the openhab ui. This is the same behavior for all values ( set points, fan mode, thermostat mode, even actual temperature being reported back from thermostat)

Regards
Michael

berndpfrommer · 2016-03-21T10:20:30Z

Something is wrong: the device answers to the query with a NACK. I
recommend you go back to the terminal and try if it responds to any of the
data queries. It may require a different checksum calculation than the
2441th.
On Mar 20, 2016 10:39 PM, "integrul" notifications@github.com wrote:

I will definitely test the new device 2441V and report back the results of
my testing. Thank you for your support on this matter.

With regards to the initialization, all of the values in openhab are null,
I have set my polling interval to 100 seconds ( I only have 1 insteon
device) just to test. And there is simply null values in the user interface
until I change them. Example - Increment the heat setpoint from the openhab
ui then the heat setpoint a) updates on the thermostat to the revised value
b) shows corretly in the openhab ui. Similar, if I increment the heat set
point on the physical thermostat it then changes from null to the correct
value in the openhab ui. This is the same behavior for all values ( set
points, fan mode, thermostat mode, even actual temperature being reported
back from thermostat)

This is what the log reports
2016-03-06 22:22:52 INFO o.o.b.i.InsteonPLMActiveBinding[:595]- modem
database has 2 entries!
2016-03-06 22:22:52 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db
entry: 14.B9.48
2016-03-06 22:22:52 DEBUG o.o.b.i.InsteonPLMActiveBinding[:600]- modem db
entry: 31.46.7B
2016-03-06 22:22:52 INFO o.o.b.i.InsteonPLMActiveBinding[:611]- device
14.B9.48 found in the modem database and the modem controls groups [0x00]
and responds to groups [0xEF,0x01,0x02,0x03,0x04,0x05].
2016-03-06 22:22:52 DEBUG o.o.b.i.internal.driver.Poller[:64]- start
polling device
14.B9.48|data1b_group->ThermostatData1bGroup(0:0:0)|tempcelsius->ThermostatTemperatureCelsius(1:0:2)|humidityhigh->ThermostatHumidityHigh(0:1:2)|tempfahrenheit->ThermostatTemperatureFahrenheit(1:0:2)|data1_group->ThermostatData1Group(0:0:0)|stage1duration->ThermostatStage1Duration(0:1:2)|humiditylow->ThermostatHumidityLow(0:1:2)|systemmode->ThermostatSystemMode(1:1:3)|isheating->ThermostatIsHeating(1:0:3)|fanmode->ThermostatFanMode(1:1:3)|iscooling->ThermostatIsCooling(1:0:3)|heatsetpoint->ThermostatHeatSetPoint(1:1:3)|coolsetpoint->ThermostatCoolSetPoint(2:1:3)|humidity->ThermostatHumidity(1:0:2)|lastheardfrom->GenericLastTime(0:0:0)|data2_group->ThermostatData2Group(0:0:0)|acdelay->ThermostatACDelay(0:1:2)|backlightduration->ThermostatBackLightDuration(0:1:2)
2016-03-06 22:22:52 DEBUG o.o.b.i.i.d.RequestQueueManager[:96]- starting
request queue thread
2016-03-06 22:22:52 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken
off direct: ThermostatData2Group(0:0:0)
OUT:Cmd:0x62|toAddress:14.B9.48|messageFlags:0x1F=DIRECT:3:3|command1:0x2E|command2:0x02|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x92|userData14:0x96|
2016-03-06 22:22:52 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next
request queue processed in 500 msec, quiettime = 500
2016-03-06 22:22:52 DEBUG o.o.b.i.internal.driver.Port[:382]- writing
(500):
OUT:Cmd:0x62|toAddress:14.B9.48|messageFlags:0x1F=DIRECT:3:3|command1:0x2E|command2:0x02|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x92|userData14:0x96|
2016-03-06 22:22:52 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device
queue for 14.B9.48 is empty!
2016-03-06 22:22:53 DEBUG o.o.b.i.InsteonPLMActiveBinding[:581]- got msg:
IN:Cmd:0x50|fromAddress:14.B9.48|toAddress:31.46.7B|messageFlags:0xAF=NACK_OF_DIRECT:3:3|command1:0x2E|command2:0xFB|
2016-03-06 22:22:53 DEBUG o.o.b.i.i.device.DeviceFeature[:264]-
14.B9.48:GenericLastTime publishing: 2016-03-06T22:22:53
2016-03-06 22:24:32 DEBUG o.o.b.i.i.device.InsteonDevice[:374]- gave up
waiting for query reply from device 14.B9.48
2016-03-06 22:24:32 DEBUG o.o.b.i.i.device.InsteonDevice[:379]- qe taken
off direct: ThermostatData2Group(0:0:0)
OUT:Cmd:0x62|toAddress:14.B9.48|messageFlags:0x1F=DIRECT:3:3|command1:0x2E|command2:0x02|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x92|userData14:0x96|
2016-03-06 22:24:32 DEBUG o.o.b.i.i.device.InsteonDevice[:399]- next
request queue processed in 500 msec, quiettime = 500
2016-03-06 22:24:32 DEBUG o.o.b.i.internal.driver.Port[:382]- writing
(500):
OUT:Cmd:0x62|toAddress:14.B9.48|messageFlags:0x1F=DIRECT:3:3|command1:0x2E|command2:0x02|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x92|userData14:0x96|
2016-03-06 22:24:32 DEBUG o.o.b.i.i.d.RequestQueueManager[:132]- device
queue for 14.B9.48 is empty!
2016-03-06 22:24:32 DEBUG o.o.b.i.InsteonPLMActiveBinding[:581]- got msg:
IN:Cmd:0x50|fromAddress:14.B9.48|toAddress:31.46.7B|messageFlags:0xAF=NACK_OF_DIRECT:3:3|command1:0x2E|command2:0xFB|
2016-03-06 22:24:32 DEBUG o.o.b.i.i.device.DeviceFeature[:264]-
14.B9.48:GenericLastTime publishing: 2016-03-06T22:24:32

Regards
Michael

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#7 (comment)

integrul · 2016-03-24T03:16:41Z

OK I will try that. In the mean time I tested your update.
I updated from the repository ( I can see thermostat2441V.py in /python)
edited my init (see below)
from thermostat2441V import*

th = Thermostat2441V("kitchen_thermostat", "14.B9.48")

then I did
ant compile
ant jar
ant run

following is the error:
[java] Insteon Terminal
[java] Traceback (most recent call last):
[java] Failed to initialize python interpreter:
[java] File "", line 1, in
[java] SyntaxError: ("mismatched input '' expecting EOF", ('./init.py', 47, 1, ' th = Thermostat2441V("kitchen_thermostat", "14.B9.48")\n'))

I noticed that in /python there is no thermostat2441V$py.class file being created.

Not sure If I missed any steps?

berndpfrommer · 2016-03-24T15:07:41Z

tried it, works for me. It compiles a python class

from thermostat2441V import *
fooThermostat = Thermostat2441V("kitchenThermostat", "32.f7.2c")

(some bad character somewhere)?

integrul · 2016-03-25T16:31:01Z

hmm, well I deleted init.py and started over... seemed to be an issue there. Anyway it works. I nuked my db in the 2114V and re added the entries so that appears to be supported. And working as intended.

There is an issue with data2 though. So if I understood correctly when it polls it gets the information from data1 data1b or data2 which then gets unpacked and populates the item values in openHAB. but if an event occurs on the thermostat then the out-of-band messages receive directly this information and populate the items. It appears that only the out-of-band messages are working and that's why when something changes (ie: setpoint via thermostat) then it updates in openHAB.

I did to a query on data1, data1b and data2 and only data2 fails. This appears to be the most important one.

ReadData2MsgHandler got msg: IN:Cmd:0x50|fromAddress:14.B9.48|toAddress:31.46.7B|messageFlags:0xAF=NACK_OF_DIRECT:3:3|command1:0x2E|command2:0xFB|
ReadData2MsgHandler got ack, waiting for ext msg!
ReadData2MsgHandler got no reply!

I was able to find the developer's guide for the 2441V but if I understand correctly even if this was supported in insteon-terminal I Would have to make a custom deviceType with custom features in openHAB. I have attached the guide.

Any guidance or direction you could provide would be great. I have a very limited understanding of the insteon protocol. But I am willing to put in the effort to get it working.

2441Vdev-052013-en.pdf

Thanks again for your help
Michael

pfrommerd closed this as completed Jul 27, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

database incomplete, reload() and retry! #7

database incomplete, reload() and retry! #7

integrul commented Mar 19, 2016

pfrommerd commented Mar 19, 2016

pfrommerd commented Mar 19, 2016

integrul commented Mar 19, 2016

integrul commented Mar 19, 2016

pfrommerd commented Mar 20, 2016

integrul commented Mar 20, 2016

integrul commented Mar 21, 2016

berndpfrommer commented Mar 21, 2016

integrul commented Mar 21, 2016

berndpfrommer commented Mar 21, 2016

integrul commented Mar 24, 2016

berndpfrommer commented Mar 24, 2016

integrul commented Mar 25, 2016

database incomplete, reload() and retry! #7

database incomplete, reload() and retry! #7

Comments

integrul commented Mar 19, 2016

pfrommerd commented Mar 19, 2016

pfrommerd commented Mar 19, 2016

integrul commented Mar 19, 2016

integrul commented Mar 19, 2016

pfrommerd commented Mar 20, 2016

integrul commented Mar 20, 2016

integrul commented Mar 21, 2016

berndpfrommer commented Mar 21, 2016

integrul commented Mar 21, 2016

berndpfrommer commented Mar 21, 2016

integrul commented Mar 24, 2016

berndpfrommer commented Mar 24, 2016

integrul commented Mar 25, 2016