grovepi
grovepi copied to clipboard
adkron
Should we keep polling
Polling gives us a friendly interface for sending event and messages, but it also limits some of the more advanced work that someone may want to do with their systems. It also defines the controls that an end user has when using the library.
For 1.0 should we pull the polling out into a new GenServer for end-user use? Should we drop it entirely? Should we keep it the same as it is?
Do you have a non-polling use case? The GrovePi isn't capable of sending notifications since its interface is I2C. Or maybe I'm misunderstanding?
I guess I don't have any specifics other than wanting to have a little more control over what is going on. I guess we could offer a default server, and then a module. So GrovePi.Lighting would be the server, but if they want more control we can also expose GrovePi.Lightning.Sensor?
I'm not sure we can delete the Polling module with deleting or re-writing a number of our existing modules (e.g. DHT, Button, Sound, & Potentiometer).
I read through your lightning-sensor branch and saw that implemented your own polling functionality.
Did you run into problems with getting the data you wanted back from polling, setting triggers, sending commands to update the configuration of the sensor, or was it another issue?
The polling that is in place based on a pin. I might have not been thinking at the time. I felt overwhelmed by the system I had put in place. Maybe it just needs some rework.
Amos King Binary Noggin
On Mar 9, 2018, at 18:24, Axel Clark [email protected] wrote:
I'm not sure we can delete the Polling module with deleting or re-writing a number of our existing modules (e.g. DHT, Button, Sound, & Potentiometer).
I read through your lightning-sensor branch and saw that implemented your own polling functionality.
Did you run into problems with getting the data you wanted back from polling, setting triggers, sending commands to update the configuration of the sensor, or was it another issue?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Oh, I see now, all of the APIs expect a pin. If you could pass a parameter to the existing Polling module to enable I2C read & write, would that have been enough? I guess you would also need to subscribe to an address or device rather than a pin, so a fairly large update would be required. I wonder if you could extract an I2CPolling module from your lightning-sensor branch?
I noticed you added Protocol & Behaviour . I have to read up on those features, I haven't used them before.