<pre>

Enable dallas sensor module on PIN 23

dallas:

• pin: 23
  update_interval: 60s

The sensor itself

sensor:

• platform: dallas

  flash the config fist without the sensor block

  and pick the dallas address from the log

  address: 0xCD012062C7DCFFFF
  resolution: 12
  id: mysensor
  filters:

  generate the median from 5 values to improve the quality

  the sensor will transmit a value to influxdb each 5 minutes

  • median:
    window_size: 5
    send_every: 5
    send_first_at: 5
    on_value:
    then:

    send the data

    • http_request.post:
      url: https://metrics.example.com/write?db=sensordata

      esphome is not able to verify a certificate

      verify_ssl: false
      headers:

      influxdb 1.x uses basic authorization

      In a Linux shell:

      echo -n "username:password" | base64

      Authorization: 'Basic YWxpY2U6cGFzc3dvcmQ='

      a few lines of C code to generate the influxdb request data

      https://docs.influxdata.com/influxdb/v1.8/guides/write_data/#write-data-using-the-influxdb-api

      body: !lambda |-
      char buf[64];
      sprintf(buf, "%0.1f", id(mysensor).state);
      return ((std::string) "temperature,group=outdoor,locationkey=example-sensor,stage=test,platform=esphome,sensor=dallas value="+buf).c_str();
      </pre>

When loading firmware, I get a message like Connecting ....._.....__..... and it eventually times out.

The programming application needs to reboot the ESP32 while gpio.2 is in a low state to put it in bootloader mode. The USB/Serial control pins normally do this on well designed hardware. Some hardware, especially older dev kits, have trouble holding the boot pin in the low state long enough. You might also have circuitry tied to that pin that is holding it in the wrong state.

Most dev kit modules also have a boot button connected to gpio.2. If you hold this down while the ESP32 reboots, then release it it when you see the Connecting .....___. It will usually fix the problem.

Some poorly designed hardware cannot reboot the ESP32. If this is the case you should hold the boot button, click the reset button (often labeled EN) and then release the boot button when you see the Connecting .....___

If the above ideas do not help and you are using a removable module, try programming the module with it removed from the controller.

This is not an issue with our firmware or install scripts. Please don't vent your frustration on us. contact the supplier of your part.

If you upgraded your Ender 3 V2 printer from the stock Creality V4.2.2 mainboard to the Creality V4.2.7 silent mainboard, you might notice some issues with controlling your machine. Most likely, you won’t be able to control the motion of components on your machine, so actions like homing an axis or moving the printhead a certain distance won’t work.

This problem is caused by a difference in the pinout schemes between the V4.2.2 and V4.2.7 boards. Luckily, one user found that all you need to do is swap the pinout numbers for the “step_pin” and “dir_pin” in the printer configuration file. You can follow the steps below to make the necessary adjustments:

Open the “printer.cfg” file through your web interface
Search for the “stepper_x” section and adjust the lines below to read:
step_pin: PB9 dir_pin: PC24+
Search for the “stepper_y” section and adjust the lines below to read:
step_pin: PB7 dir_pin: PB8
Search for the “stepper_z” section and adjust the lines below to read:
step_pin: PB5 dir_pin: !PB6
Search for the “extruder” section and adjust the lines below to read:
step_pin: PB3 dir_pin: PB4
Save the changes to the file and update the firmware.