For example an LED should be able to ask about it's current state.
This is a kinda interesting problem because when you add_digital_hardware it sets the pin mode to in, that logic should be updated when it needs to be only.
More investigation is needed.
Yeah, the names @digital_hardware and @analog_hardware are a bit deceptive, since they only hold input hardware, not output components like an LED. So the add_digital_hardware, add_analog_hardware and corresponding removal methods actually do the right things for their purpose.
If you want methods to cache and return the state of the LED, which is a good idea, try writing them into the LED component class. Look at the Button class which caches the values in a @state variable to make sure that the callbacks only fire when the state of the button changes.
There is a way to get the state of an output pin at the Arduino level. But, this shouldn't be necessary if all you're using is Dino. Though, I'm already finding myself working on sketches for home automation where I want some logic to always run in the Arduino loop, regardless of whether Dino is connected.
In these cases, the state of output hardware may change independent of any message from Dino, so we'll want a way to send a message to Dino so it can update the state of the Ruby instance representing that hardware.
It's simple, but will rely upon some things already done in #22, so I may include it there or in a subsequent pull.
Handled in #34