Announcement

Collapse
No announcement yet.

Raspberry GPIO Future Roadmap?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Raspberry GPIO Future Roadmap?

    I believe this would be directed towards Spud, but I am also interested in hearing from the community on where this plugin is going.

    I see there are lots of threads started about servos, other analog, inputs and outputs through the GPIO pins... Can we get some of these implemented?

    Questions:

    Are there any technical roadblocks?
    Are these features in the roadmap? Estimated Timeline?

    I am trying to make a decision myself on which path I am going with a few projects and if needed I`ll write a plugin instead of one-off work arounds for my own stuff to work if others are interested. Also if it is going to be included within this plugin I`ll simply hold off or do a work around for now until it is available.

    Thanks in advance.

    #2
    I always thought common GPIO device profiles would be helpful for setting things up in Raspberry IO. For example a list of devices from relays, sensors, input and output devices that the plugin would auto create with known good settings.

    Plug in a DHT22, set PIN#X to sensor->DHT22 and voila have a device created with temp and humidity reporting, or PIN#Y is set to output->relay and an on/off device is created, etc..

    Pi in the sky, no idea how much work would go into adding that functionality or how many devices to support, but there are a handful of popular options that I'm sure people are using that would find this useful.

    Comment


      #3
      My opinion is that RPi is overkill and generally inappropriate for interfacing low level GPIO. If there is a RPi App that uses GPIO then great to have this resource within RPi. If all that is being gone is interfacing a GPIO then a microcontroller is a better choice. Arduino family, ESP8266, ESP32 come to mind. Coupling with HS is via Ethernet, either wired or wireless. Protocols of HTTP/REST or MQTT have readily available libraries. MQTT has multiple HS plugins. The are also HTTP options for interfacing HS.

      Comment


        #4
        I can pick up a Pi Zero W for $14CDN vs an ESP32 which seem to be $18CDN or so, so if the Pi is overkill then it is most certainly the best option given the pricepoint\capability.

        Comment


          #5
          I will of course defer to Spud since he wrote the plugin, but I believe he has implemented only GPIO at this time.

          Raspberry PIs have pins that can be configured for SPI and others for I2C and even a serial port UART. SPI (serial peripheral interface) and i2C (inter-integrated circuit) as well as old fashioned UART serial port are generic data communication protocols, and they lay out no standards for the data itself. That is unique to whatever device is connected to the pins and requires software running on the Pi that includes specialized libraries to interpret that data and make it useful. The raw data is not something you can pass back to an HS3 plugin for interpretation. Even within these protocols there are still more specific configuration parameters to make them work in particular ways.

          GPIO is much simpler. There is no protocol or differences from one device to another because it is a straight-forward on or off to or from the GPIO pins with no need for interpretation. The pull-down resistor for the inputs is about the only option. Your relay hat or contacts go to pins and the plug in only has to read/write the binary state of on/off.

          In the example of the DHT22 Humidity/Temp sensor, it has a data pin, 5V and ground. Humidity and temperature are, of course, analog values that have to be converted to a digital value, so on the DHT22 "board" it receives something like 0-20mA analog current which is converted to a number like 0-127. That is what comes through the data line to the Pi. That raw useless number is then converted by a Python library to something useful like numbers from -40 to 60 (C) and humidity from 0-100 (%).

          A stepper motor works on an entirely different principle. A square wave is pulse-width-modulated (PWM) to tell the motor exactly what position it should be in. Different motors and servos can have different characteristics, and are run by stepper-motor controllers because even the Pi itself is not fast enough to generate accurate PWM signals.Those boards, in turn, are varied and have different initialization and control parameters.

          So, in a way, asking Spud to support I2C or SPI so we can run servos, stepper motors, sensors or pixel strips via the plug in is like asking the electric company to produce electricity in a way that makes you steak for dinner. There are many devices and parameters that get it from the store to the dinner plate they are not in control of nor can they predict.

          GPIO is more like asking the electric company to produce 110V at 60Hz and you determine what's plugged in and how to control it at your home.

          Comment


            #6
            For those interested in the DHT22 in particular, the easiest way to integrate that into HS is to install Raspberry Pi OS, Apache w/ PHP, install AdaFruit-DHT22 library and then modify the Python example at https://medium.com/initial-state/bui...s-730a40f1fb60 to skip the cloud and just write out JSON or raw text values to a file in the /var/www/html folder.

            Use PHP to make an index.php that does nothing but include this file. Then, from the HS3 system, call the website at the IP address, read the values in your favorite format, and update a virtual device in HS3. Works great, and never has so much processing power and software been brought to bear to produce so little data.

            Comment

            Working...
            X