Random thought: split off "concrete" device impelementations

[EAGrahamJr]

I was scrolling through the list of devices provided and realized something: there's a lot of stuff in there that I'm likely to never use (or even use again, in the case of my own contributions). Also, it would seem to be a never-ending battle to "try to keep up" and ensure everything keeps working -- I would be amazed if you actually have all of this stuff on your workbench! And then there's all the new stuff - I've added 7 devices just of my own junk, at least two of which I'm also unlikely to actually need 🙄 .

I think if the devices are examined on a functional level, it might be possible to spin off one or more specific "categories" of devices (like the imu) and still provide more than enough concrete implementations of "devices" to build off of. I also understand this would be a huge undertaking.

[mattjlewis]

Definitely don't have all of this stuff on my workbench! Most are packed away in boxes, slowly getting more organised.
Definitely like the idea of moving functional aspects out of the device specific implementation class. It does seem that on the whole most of the code is in the low-level communication.
Definitely see the benefit of separating device independent logic, off the top of my head:

• Things like sensor specific value conversions (temperature Celsius<->Fahrenheit, altitude compensation, etc.)
• Motors (that API definitely needs improving)
• Stepper motors (you're current work)
• IMUs, the mathematics here gets a bit too complicated but there would be huge value smoothing, etc. I know there is a huge amount that can be done here and I haven't touched this code in years
• Interfaces for "streaming" digital and analog input data and events
• I think the expander boards should have their own package (GPIO, Analog Input, motor, etc) - open to package naming suggestions, e.g. "c.d.devices.expansion" or even "c.d.expansion" ?
• Maybe create a "c.d.devices.environment" package for things like temperature, pressure, humidity, etc. sensors?
• Create a "c.d.devices.display" package for LCD and OLED devices?
• On the subject of OLED, I would definitely like to provide a simplified interface for drawing to bitmap displays (lines, fonts, etc), e.g. https://esphome.io/components/display/index.html#color
• In fact we can take quite a bit of inspiration from this project: https://esphome.io/components/index.html. I've been using it recently to place a load of ESP8266 + BME280 devices around my property, all sending data over MQTT to an Influxdb (using Telegram + Influx + Grafana)

[mattjlewis]

The biggest area of concern that I have is regression testing the various boards that are "supported". Other than refactoring errors (the LCD implementation!), the I2C/SPI devices seem to be fairly stable, I have greater concerns with regression testing across all of the physical boards, definitely need to make it easier to support new SBCs. FYI I suspected I will be distracted by the new Orange Pi 5 that arrived today...

[EAGrahamJr]

Yeah, I think generalized categories with the explicit device-type implementations.

• One problem with splitting up "sensors" into different packages is you could end up with conflicts on "hybrid" sensor platforms (e.g. Luminosity and Distance - I got one).
• "streaming"? I don't think I've run across one of those yet...
• c.d.expander.blah works for me - "device" is pretty much implied
• "environment" vs "sensors"
• 👍 for "display"
• For drawing stuff on OLED, I thought about it for a while and, in my own stuff, I decided to just try not to be all things to everything and uses a java.awt.image.BufferedImage as the main display buffer.
  • This makes it pretty simple to create a Graphics2D object to do all the drawing/filling/whatever using the standard AWT libraries (which also extends to anything using AWT).
  • display function
  • simple gauge

I do like how everyone is basically re-implementing stuff in their own ... idioms. 😏

[mattjlewis]

• Streaming - review APIs to ensure diozero fits in a reactive / event streaming / functional programming paradigm, expand the use of functional interfaces (FloatConsumer, FloatSupplier, etc. in c.d.api.function + OOTB JDK java.util.function)
• Ability to filter an event stream, e.g. Kalman filter, median, removing anomolous readings (min, max), sliding window moving average (suggest a different package as would definitely bring in additional dependencies, i.e. Hipparchus as used by diozero-imu-devices
• Refactor the c.d.animation package - a really useful concept but currently a poor API and spawns a thread per animation instance - my initial intention was to use for smoothing servo transitions in robotics on the assumption that it isn't good practice to go straight from min to max
• LED / OLED Displays - you're right, would always piggy back of J2D buffered image and drawing functions, just I quite liked the simplicity of the higher-level APIs, such as positioning text within the bounds of the display (top, bottom, left, centre etc), display orientation (flipped, rotated), colour profile, etc.

[EAGrahamJr]

Ah, threading and statistics/metrics. I've already run into threading issues with the expansion board (too many requests too fast and 💥 - requires hardware reset). My own notion along this line was more of an internal event bus (pub/sub). I think I may have tried to take my own experiments a little too fine-grained (thus the hardware issues), but it does point out the problem with multi-threading and hardware access: at some point, there's going to be contention on either a hardware device or a bus. How/where do you deal with that? And smoothing: is that on the consumer or the producer?

That's one of the reasons behind the recent refactor of the stepper motors: the chopper (SilentStepStick) drivers are radically different than the basic ones. The basic drivers rely heavily on software timing for speed, thus becomes non-linear and unpredictable. (I can't even get a unipolar and bipolar stepper to agree on "steps per rotation".)

Regarding OLED and some "primitive" functions: generic text functions sound good until you realize you have to get into font management, too (name, size, weight, ascent, descent). The library mentioned above looks nice, but J2D does all of that (one could even use something like JFreeChart!). It was kind of a PITA to even create a "generic" gauge!

I think some base color profiling (e.g. palette conversion) would be necessary (as in my case, take a color picture and convert to gray-scale). The J2D stuff is pretty easy to use, and removes any burden of trying to maintain some sort of "buffer", when whatever app is using the device can just re-draw their own "canvas" and simply tell the display to show it.

[EAGrahamJr]

Just saw something on the Adafruit forum that also complicates things: some sensors require "clock-stretching" on the hardware platform. Now it's really complicated... 😀