key error when thermostat not found in config

[snizzleorg]

I get my logs flooded by bt-mqtt when I have MQTT messages referring to thermostats that do not exist in workers config.

Because I cannot cover my whole flat with one gateway I have two gateways, each handling different areas/thermostats.

I would expect that bt-mqtt handles this gracefully and just ignores keys which are not found in the config.

● bt-mqtt-gateway.service - Bluetooth MQTT gateway
   Loaded: loaded (/etc/systemd/system/bt-mqtt-gateway.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-02-26 04:00:01 UTC; 13h ago
     Docs: https://github.com/zewelor/bt-mqtt-gateway
 Main PID: 9973 (python3)
   CGroup: /system.slice/bt-mqtt-gateway.service
           └─9973 /usr/bin/python3 /home/pi/bt-mqtt-gateway/gateway.py

Feb 26 17:22:35 kitchentunes python3[9973]: KeyError: 'BedroomL'
Feb 26 17:22:35 kitchentunes python3[9973]: 'BedroomL'
Feb 26 17:22:35 kitchentunes python3[9973]: Traceback (most recent call last):
Feb 26 17:22:35 kitchentunes python3[9973]:   File "/home/pi/bt-mqtt-gateway/gateway.py", line 37, in <module>
Feb 26 17:22:35 kitchentunes python3[9973]:     mqtt.publish(_WORKERS_QUEUE.get(block=True).execute())
Feb 26 17:22:35 kitchentunes python3[9973]:   File "/home/pi/bt-mqtt-gateway/workers_manager.py", line 26, in execute
Feb 26 17:22:35 kitchentunes python3[9973]:     messages = self._callback(*self._args)
Feb 26 17:22:35 kitchentunes python3[9973]:   File "/home/pi/bt-mqtt-gateway/workers/thermostat.py", line 78, in on_command
Feb 26 17:22:35 kitchentunes python3[9973]:     thermostat = self.devices[device_name]
Feb 26 17:22:35 kitchentunes python3[9973]: KeyError: 'BedroomL'

[zewelor]

I don't think global silent ignore by default is good solution for debugging etc. There is flag -q for gateway, it should silence most of the errors. Also then why ignore only this error and not others, how to choose ? Also why there is such error ? Same configs on both gateways ? Same global_prefix ?

[snizzleorg]

Thanks for the answer. Yes global_prefix is the same, the client_id differs.

I think the missing key should be logged but it is not really an exception - is it?

I try to debug why some of my thermostats would not respond or cannot be connected to (while previously they were working fine) and I have the log full of those key errors. Which is not very convenient. If they safely can be ignored than that's ok i guess...

BTW. Do I need to pair the eqbt3 thermostats? I was under the impression that this is not necessary but since I cannot get bt-mqtt gateway to talk to some of them while before it worked I am unsure...

[zewelor]

I think maybe better would bo to make different global_prefix or prefix for thermostats like first_floor_thermostat / second_floor_thermostat etc. Have you tried -q option, for silencing errors ?

I've ended up pairing all thermostats, I also got some weird connection errors sometimes. Now they all work stable. Also be sure that only single gateway tries to access one thermostat.

[cybe]

I agree with both of you ;)

You should preferably use different prefixes to address separate bt-mqtt-gateways. But missing devices should not result in an uncatched exception, but rather in a appropriate warning.

[cybe]

@snizzleorg

BTW. Do I need to pair the eqbt3 thermostats? I was under the impression that this is not necessary but since I cannot get bt-mqtt gateway to talk to some of them while before it worked I am unsure...

Pairing is not needed. But make sure only one client communicates with a thermostat at any given time. Especially disable Bluetooth on your smartphone if you used the official app, as that app created a pairing between your smartphone and the thermostat which possibly blocks other connections.

[snizzleorg]

@cybe Thanks for your suggestion. But If I'm not at home (for example now) then my phone should definitely not interfere with the connection - right? Or is the fact that the thermostat is paired (or was paired once) part of the problem?

I still get the connection failed errors although I can easily see then with hcitool lescan. two of the bt-mqtt is not able to connect to anymore. While it was working for several months without any problem. I tried taking the batteries out to reset them etc. No dice.

[zewelor]

For my pairing with the rpi worked on some thermostats. Before ( not sure what changed ) they worked without pairing. What I've done: Put each thermostat into pairing ( get pin screen ). Do pairing procedure and trust / auth on rpi zero.

After that all of them works for monts without any problem.

[snizzleorg]

@zewelor could you let me know how exactly did you pair them? I will try and see if I get a stable connection going this way...

[zewelor]

I've followed this tutorial: https://wiki.archlinux.org/index.php/bluetooth#Pairing . I'm using raspbian on rpi zero

[cybe]

@cybe Thanks for your suggestion. But If I'm not at home (for example now) then my phone should definitely not interfere with the connection - right? Or is the fact that the thermostat is paired (or was paired once) part of the problem?

No, you should be fine then @snizzleorg.

I still get the connection failed errors although I can easily see then with hcitool lescan. two of the bt-mqtt is not able to connect to anymore. While it was working for several months without any problem. I tried taking the batteries out to reset them etc. No dice.

Some more pointers:

• Do you run bt-mqtt-gateway on a Raspberry Pi in conjunction with Wifi? Those are known to interfere with each other
• Do you have another program that accesses the Bluetooth adapter on your device?
• What are those "connection failed errors" exactly? Is an exception thrown? Is it a RuntimeError by any chance?

[hechi]

Hey guys, I faced a similar problem with the unknown device name. I agree with @cybe that indeed it would be better to use a different prefix for different gateways but nevertheless, in my opinion, the application should not terminate because of this error. I hope the small change with #150 is ok for you guys :)