Paul, The current field_map behaviour is deliberate, it probably doesn’t help that I have not documented the behaviour yet. The expected behaviour is:
1. If the user specifies nothing the default field map is used. (The default field map can be viewed by running the driver directly with the —default-map command line option. The default field map happens to be constructed from the field map dict and battery map dict) 2. The user can specify a mapping under [field_map], in this case the user specified field map replaces the default field map, in other words the user takes full responsibility for the field map. You can run the driver directly using the —live-data command line option to see what data , including battery state data, is available from the GW1000 for mapping. You can extend the [field_map] with [field_map_extensions] but why would you. 3. If the user is happy with the default field map but wants to map a few fields differently they can use [field_map_extensions] to modify the field map rathe4 than having to specify every mapping with [field_map]. [field_map_extensions] are used to modify the field map (typically the default field map), basically any GW1000 ‘fields’ in the [field_map_extensions] are removed from the field map then the [field_map_extensions] entries are added to the field map. The behaviour above is fairly much standard among drivers that use field/sensor maps with [field_map] and [field_map_extensions]. I will document this in the driver wiki shortly. Gary -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9cfb56c1-fc22-4281-b4a5-4e0bf84efcabo%40googlegroups.com.
