Should we keep polling about grovepi HOT 5 OPEN

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?

from grovepi.

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?

from grovepi.

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?

from grovepi.

from grovepi.

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.

from grovepi.