Enhancement to rpiGPIOSensor

Question

Enhancement to rpiGPIOSensor

Mr-Eskildsen opened this issue 7 years ago · 13 comments

Allow class rpiGPIOSensor to report ON / OFF as well as OPEN / CLOSED.
Add functionality to control if it is considered as active high or low. Eg. a magnetic door contact would be active LOW (indicating open door)

I agree

Answer 1 · 2017-12-07T15:19:14.000Z

I'm ambivalent about the first one. I do think that the feature could be useful, but, at least when using MQTT, it is so easy on the receiver side in openHAB at least, to transform it to anything needed. Also, since this is a sensor, again thinking of openHAB concepts, a Contact is the appropriate type of Item, not a Switch which should be used for actuators.

But that distinction is often ignored and sensorReporter is not strictly an openHAB tool.

I'll have to think about how to implement this. If I do implement it you will be able to choose the message as anything you want, not just choose between ON/OFF and OPEN/CLOSED.

For the second one, unless I'm mistaken in what you are asking about, the PUD option already does this.

Answer 2 · 2017-12-07T22:03:07.000Z

Thanks for your answer. Let me enhance the second point at little. I have bought some magnetic door sensors. When the door is closed it is connected (eg. High), else it is Low. I would like it to report CLOSED when the door is CLOSED and vice versa. As I understand the PUD it doesn't help me, or am I wrong? Best regards Martin Den 07-12-2017 kl. 16:19 skrev Richard Koshak:

…

I'm ambivalent about the first one. I do think that the feature could be useful, but, at least when using MQTT, it is so easy on the receiver side in openHAB at least, to transform it to anything needed. Also, since this is a sensor, again thinking of openHAB concepts, a Contact is the appropriate type of Item, not a Switch which should be used for actuators. But that distinction is often ignored and sensorReporter is not strictly an openHAB tool. I'll have to think about how to implement this. If I do implement it you will be able to choose the message as anything you want, not just choose between ON/OFF and OPEN/CLOSED. For the second one, unless I'm mistaken in what you are asking about, the PUD option already does this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFTMe-IgpzgqDXQy2YVJdEFDC0JwGxdYks5s-AHzgaJpZM4Qlt1j>.

Answer 3 · 2017-12-08T16:56:51.000Z

I'm not an expert on GPIO, but I believe that PUD does exactly that.

[furiously googles]

Nope, I'm wrong. The PUD sets the "default value", it doesn't swap the inputs like I thought.

OK, we will add that to the list of things to fix. I can see two approaches:

Set a flag that lets you choose what 1 means on the pin. So you can choose to send OPEN on 1 or OPEN on 0.
Let the user set the String that gets sent for 1 and 0.

1 is simpler to implement but 2 is much more flexible, but that flexibility comes at the cost of complexity in the .ini file.

Answer 4 · 2017-12-14T20:54:24.000Z

How about an option such as

Values: OPEN,CLOSED

Code loads it into an array such as values[] and then simple sets the value by using (pseudocode)

self.publish(values[self.state])

since the pin value will only be zero or one.
Just a thought.

Answer 5 · 2017-12-14T21:14:27.000Z

That makes sense. From a user's perspective, is it easier to understand as one option like this or split into two options? I like the terseness of having just the one option but several users of sensorReporter have pretty low technical skills.

If we keep it as one value, I think we should be sure to handle whitespace appropriately.

Does it make sense to get really fancy and support JSON/XML messages? I'm not sure that is feasible with one Values option, and I'm not sure there would be much demand for that anyway.

Does it make sense to support full sentences for the messages?

I'm just trying to think this through.

I like the one option with two one word messages, but once you give an inch, people will ask for a mile. ;-)

Answer 6 · 2017-12-15T19:56:42.000Z

I think if people want JSON or XML messages they need to approach it in a different way and this is likely not the solution for them. The beauty of this project is simplicity with flexibility. Currently the project is very approachable particularly by people who may not be so technical.

I like one option. It keeps the code simpler since you don't have to deal with the scenario where you have an ON option but the user failed to provide an OFF option. With one value you can quickly generate an error if the split fails to give you two outputs.

Answer 7 · 2017-12-15T20:56:44.000Z

One option it is. I agree, if they need JSON or XML, at a minimum they will want to write their own extension.

The code should also spit out an error if the split gives you more than two outputs. I'd rather get an error than unexpected behavior.

Answer 8 · 2018-01-19T14:43:16.000Z

I believe the just merged PR #46 implements everything discussed here, correct? If so we can close this one.

Answer 9 · 2018-01-19T18:54:54.000Z

I took a look at this and currently it does not address his issue. The code I added implements a similar logic flow for the rpiGPIOConn class in that sometimes you want a true value to turn off the pin. In my case this is used to show a blue light when motion is detected and a red light when not hence a value of zero needs to turn on the red LED and turn off the blue LED. Implementing this is pretty trivial though. I would be happy to send you a PR for it since I might need that functionality too in the future.

Answer 10 · 2018-01-19T20:35:30.000Z

I'd love to accept the PR. You will get to it long before I get a chance.

Thanks!

Answer 11 · 2018-05-23T22:31:05.000Z

I beleive everything discussed has been merged. Closing. Will reopen if I missed something.

Answer 12 · 2018-05-30T21:10:47.000Z

I thinks it's all good.

Thanks.