DanielDecker

I think the discussion about sensor / actuator discover API fits better in this topic, since it is close related to homie. >>So sensors and actuators would get an interface...

>There is already a step for actuators where they register with the connections. This is how they tell the connection which MQTT Topic/openHAB Item to monitor for commands. We could...

>No, I'm thinking replacing that function because the current one would be irrelevant. Right now the actuator calls register on the connection passing what we currently call the cmd_src. This...

>Probably, unless we want the class to add stuff to it that might be relevant ... What class do you mean? >That is a problem, I agree. We need to...

I'd expect `Btn_Pressed_State` to be optional regardless of the configuration of `PUD` The default value for `PUD` is `DOWN` (line 95): ```python pud = GPIO.PUD_UP if dev_cfg["PUD"] == "UP" else...

I looked into this with my test system. I found 2 runtime exceptions: * `AttributeError: 'RpiGpioSensor' object has no attribute 'pud'` Triggers when `Btn_Pressed_State` is not defined, just as you...

> If it looks like this is going to take too long, we can extract just that fix and submit it as a separate PR later if we need to....

>>The homie spec recommends in such a case to set the communication status back to "initializing", publish the new sensor channels and set the status back to "ready". >But if...

I don't think there is a bug. The idea behind this routine is to make sure the remote connections (mqtt, openHAB) show the correct status for the actuator. e.g. ```...

> By publishing to `self.cmd_src` sensorReporter is basically commanding itself and by not publishing to `self.destination` nothing else is getting the state update. If anything get's published to `self.destination` at...