configure expected sensors

[epruesse]

It might be worthwhile to have a small simple configuration file in which the sensors, their type and ID are listed:

• push meaningful names to MQTT rather than obscure numbers
• work around warm up time needed to learn alarm bit
• filter neighbors' devices we don't want to accidentally snoop on
• set status of devices after restart (think device that happens to go offline, after restart, e.g. from repositioning receiver, the MQTT will still show the device as fine, no timeout shown)

[fusterjj]

These are all good points, especially avoiding the warmup time.

I will say that I kind of view the minimal configuration as a feature though; personally I like only needing to do per-sensor configuration in one place (Home Assistant) vs being required to do it in two places. However I'm sure there are some scenarios where people aren't using HASS (or something similar). So I think if this gets added it should be purely optional.

For the warm-up time, I think that one can be fixed without configuration; just cache the learned loop bit information after some time. The same caching mechanism could be used to resolve the fourth item as well--saving the current list of learned devices.

I guess I'm saying this is really two features then--1) optional configuration of names, and 2) cache device info.

[epruesse]

Yes, I was thinking to have a state file similar to known_devices.yaml in HA which is filled with discovered devices but also allows configuration with a speaking name (maybe HA will at some point learn to accept those from MQTT in a way similar to getting device names from Hue bridge or OpenZWave).

It could be something as simple as

# comment
<code>\t<name>\t<alarm_bit>
<code>\t<name>\t<alarm_bit>
<code>\t<name>\t<alarm_bit>
### autodetected ###
<code>\t<name>\t<alarm_bit>
<code>\t<name>\t<alarm_bit>

With <name> equal to <code> when auto-detected.

I don't mind the wait time so much, but if I move the antenna and reboot, I'd like to have devices that are no longer showing up marked as "FAILED", rather than staying as "OK" simply because no message was ever received from them.

Besides "configured" and "auto-detected" devices, it would be good to have the MQTT connection configurable at run time. Since it may contain a password, a config file would be preferable over command line parameters for that.

I can see whether I'll find the time to code that stuff. Should the three types of config go into one file or two?

It just could be e.g.

# mqtt connection config
mqtt_host = 10.1.2.3
mqtt_port = 1234
mqtt_user = bla
mqtt_pass = blub
# rtl-sdr config
sdr_gain = 35
sdr_paramX = 2.0
# device config
123456.name = front door 
123456.type = 8211

and

./honeywell config.file.location

[fusterjj]

That all makes sense. Yeah I guess if we can be pretty sure of not overwriting any user data then one file is fine, otherwise that's the only division I would bother with--autodetected vs explicit configuration.