search

ghoti57 / evofw3

Major overhaul of evofw2 Evohome listening software to use asynchronous radio mode
61 stars 12 forks source link

Add command for retrieving the deviceId #24

Closed dennisvbussel closed 2 years ago

dennisvbussel commented 3 years ago

Similar to issue #20

For my use-case I need to seperate the deviceId (used by the evofw3) and other devices in my system which also use 18:xxxxxx as device type. I decided to implement this feature as a seperate command !I so this will not break other functionality of the sensor.

A bit ugly IMO is the declaration of MyClass = 18. Perhaps it is nicer to define GWAY_CLASS and GWAY_ID in the gateway.h file and include that in the cmd.c

ghoti57 commented 3 years ago

The knowledge of how the Gateway class and id is generated belongs within gateway.c and should not be reproduced in cmd.c Changed my mind - see later comment [The correct way is to make MyClass and MyId global and visible via gateway.h.]

ghoti57 commented 3 years ago

Better would be a function declared in gateway.h and implemented in gateway.c void gateway_get_id (uint8_t class, uint32_t id); that returns the values of the static variables.

dennisvbussel commented 3 years ago

Agreed by leaving the class id in gateway.c, I will commit the changes (getter) once I find some spare time.

zxdavb commented 3 years ago

Pete,FYI so you know (if you don't already):

ghoti57 commented 2 years ago

knowing the device addr will not guarantee you'll know what type of device it is

I've never assumed this - and commented previously in slack. There's absolutely no need for ANY device to use a specific class number - it's role in the system is always determined by the binding. If a device binds when the controller is looking for a temperature sensor then it's a temperature sensor.

At the end of the day class+id just gives you a 32 bit device id. Splitting it into two parts probably makes manufacturing simpler and within any overall system will probably have meaning. I doubt that any of the honeywell controller code attaches meaning to any of the device class values it sees. This is shown by getting evofw3 to send any random value as its own device class+id - it always gets expected responses.

The only place I have a specific device class is in the gateway code of evofw3 because we're (vaguely) emulating an HGI

ghoti57 commented 2 years ago

I've implemented this in a way that better supports some future ideas I have for the code Preswent in evofw3 0.7.1