Add support for Analog Gauges

[petrows]

Description:

Hey Folks, i am glad to introduce brand new driver. It allows to use and indicate using analog gauges.

This driver implements support for following driver chips for analog automotive gauges (Switec X25.168, X27.168 and clones) with microstepping support:

• VID6606 (2 motors)
• VID6608 (4 motors)
• VT6608S
• AX1201728SG
• BY8920
• many others

Driver chips with microstepping is the recommended way to drive such motors, they provide much more relailabe and smooth movement with reduced noise and to avoid skipping steps.

Driver is configured to perform 320° rotation angle with 12 steps per degree. Total capacity is 3840 steps for whole scale.

Library homepage: https://github.com/petrows/arduino-vid6608

Connection:

• Connect IC VID6608 inputs F(scx) and CW/CCW to GPIO pins
• Connect RESET pin of VID6608 to VCC
• Define "VID6608 F" and "VID6608 CW" pins in Configuration / Module page

Driver adds following commands:

• Gauge : returns current gauges state
• GaugeSetX : set gauge to absolute position in range 0..3840, where X - motor index from 1 to 4, 0 for all
• GaugePercentX : set gauge position in percents in range 0..100, where X - motor index from 1 to 4, 0 for all
• GaugeZeroX : triggers gauge calibration and homing, where X - motor index from 1 to 4, 0 for all

Performance notes:

• ESP32: Driver uses background FreeRTOS task for impulse generation, as it requires microsecond precision
  for inpulses. ESP32 uses FreeRTOS API and movement is fast and smooth (very similar to real car gauges).
• ESP8266: For ESP8266 driver also works, but movement is much slower (but it is still okay for slow
  changing values, i.e. temperature). On ESP8266 speed is ~2 sec per degree.
• Driver uses delayMicroseconds() function to control impulses, and this function seems to be not really good implemented in our chipsets, so it create additional load while gauge is moving.
• Driver holds thread sleeping while gauge is not moving and does not create additional LA on ESP chip.
• Driver has some non-thread safe code, but i assume it is safe to use it like that, additionally i'd like to avoid use additional synchronization objects to reduce complexity and resources used.

Implementation examples:

Device prototypes assembled:

They both running Tasmota and environment sensors (as additional load test).

My test setup (tested both on ESP32 and ESP8266):

Detailed move test: https://youtu.be/dTKQrNPrnPg

Tasmota WebUI:

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.8
• The code change is tested and works with Tasmota core ESP32 V.3.1.6
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[s-hadinger]

Your prototypes look awesome. Any link where such enclosures can be found?

[petrows]

Your prototypes look awesome. Any link where such enclosures can be found?

Thanks! Yes, enclose what i have used: https://www.ikea.com/de/de/p/dekad-wecker-schwarz-30540479/

P.S. It is still early prototype, i will publish all documentation for it when it will complete, i am currently waiting for PCB

[s-hadinger]

This is great. I'm eager to see the evolutions

[petrows]

@arendst , thanks for merging! I will prepare also some documentation around.

I still have some ideas to-improve, but i am not sure if they have any request from community, probably option to keep source code clean is also fine.

[petrows]

Hey @s-hadinger , i think i reached my project production, please checkout my Reddit post, if you are interested: https://www.reddit.com/r/DIY/comments/1pukdly/analog_co2_sensor_for_smarthome/

[sfromis]

Looks great. 👍

I wondered about a couple of nitpicky details.....

• Usually, I'm seeing CO₂ levels of 800 ppm recommended as the threshold for "good". OTOH, I'm not too concerned about regularly going above that. YMMV.
• Having a temperature sensor inside a closed box without good airflow is not very reliable, as the ESP32 can act as a small "radiator".
• Those holes where the bells were looks like a great place for buttons. Maybe something like control of backlight, calibration, or whatever.

[sfromis]

BTW. When it comes to your point about possibly adding FRAM support to Tasmota itself, you can feasibly implement it as a separate module, after which you can do things like:

import fram
fram.write_u16(0,257)
fram.read_u16(0)
257

This way, you basically have a separate driver, instead of the code being intermingled with the project code.

Using a module can be as simple as having fram.be in the file system, and it would even be possible to solidify such a driver module to become part of the Tasmota binary without anything needed in the file system. Here's the sample code (which works for me), based on your FRAM read/write routines:

# Functions to read and write FRAM memory
# to store data during power off
# Connect and prepare i2c FRAM MB85RC04V

var fram = module('fram')

fram.init =
def (m)

  class FRAM

    static i2c_addr = 0x50

    var wire

    def init()
      self.wire = tasmota.wire_scan(FRAM.i2c_addr)
      # Check initialization
      if self.wire
        print("FRAM initialized")
      else
        print("FRAM not found")
      end
    end

    # Function to write FRAM memory, 2 bytes
    def write_u16(addr, data)
      if !self.wire
        return 0
      end
      # Split address and data into two bytes
      var addr_hi = (addr >> 8) & 0x7F
      var addr_lo = addr & 0xFF
      var data_hi = (data >> 8)
      var data_lo = data & 0xFF
      # ---------------- WRITE ----------------
      self.wire._begin_transmission(FRAM.i2c_addr)
      self.wire._write(addr_hi)
      self.wire._write(addr_lo)
      self.wire._write(data_hi)
      self.wire._write(data_lo)
      self.wire._end_transmission(true)
    end

    # Function to read FRAM memory, 2 bytes
    def read_u16(addr)
      if !self.wire
        return 0
      end
      # Split address and data into two bytes
      var addr_hi = (addr >> 8)  & 0x7F
      var addr_lo = addr & 0xFF
      # ---------------- READ ----------------
      self.wire._begin_transmission(FRAM.i2c_addr)
      self.wire._write(addr_hi)
      self.wire._write(addr_lo)
      self.wire._end_transmission(true)
      self.wire._request_from(FRAM.i2c_addr, 2)
      var value_hi = self.wire._read()
      var value_lo = self.wire._read()
      var value = (value_hi << 8) | value_lo
      return value
    end

  end

  return FRAM()

end

return fram

Obviously, it could be extended to be a more general FRAM driver, like supporting other data types.

[petrows]

Hey folks, thanks for your help and discussion :-)

Dear @arendst , i have also opened PR for documentation: tasmota/docs#1549

[arendst]

Thx. Just merged.