Switch input - iButton

.

Plugin details

Type: Switch input

Name: iButton

Status ESP32: COLLECTION A

Status ESP8266: COLLECTION A

GitHub: P080_DallasIButton.ino

Maintainer: .

Used libraries: .

Supported hardware

../_images/P080_iButtonReader1.png ../_images/P080_iButtonReader2.png

This type of reader is available at sites like Aliexpress and eBay. The wiring for these units can be somewhat confusing:

ESP           iButton (4 wires)
GPIO   <-->   1-wire/D (green) with 1k..10k Pull-up to VCC
GND    <-->   GND (red)

ESP           Resistor        LED
VCC    <-->                   Anode (black)
GPIO   <-->   470 ohm   <-->  Cathode (white)

The value for the pull-up resistor on the 1-wire GPIO pin depends somewhat, sometimes, 10k doesn’t work reliable, especially when using longer wires (> 2m), then lowering to 4k7 or 2k2 usually fixes that. For really problematic installations with high (electrical) noise levels, a 1k resistor may be needed to make it work reliable.

Description

The iButton, developed by Dallas, now Maxim, is a coded key or button, that can be used for access control or similar identity checks. They use RFID technology to transfer their ID to the receiver, once in close proximity of the receiver.

The iButtons often come in the shape shown in the image below, and can be attached to a keyring for easy access and use.

These buttons are available as read-only iButtons, and as rewritable iButtons, where the user can change the ID of the button. Both types can be read by ESPEasy, but ESPEasy does not provide tools or features to write an ID to the rewritable buttons, separate tools for that can be obtained elsewhere.

../_images/P080_iButtonExamples.png

Configuration

Device configuration

  • Name: Required by ESPEasy, must be unique among the list of available devices/tasks.

  • Enabled: The device can be disabled or enabled. When not enabled the device should not use any resources.

Sensor

  • GPIO 1-Wire: The reader only needs a single GPIO pin (and GND) to be connected. The 1-Wire hardware configured in ESPEasy requires a ca. 4k7 ohm (range 1k..10k depending on wire-length) pull-up resistor between VCC (3.3V) and the GPIO pin. Internal pull-up of the ESP is not sufficient!

Any additional wires on the receiver unit mostly are used for indicator leds, that can optionally be controlled using standard GPIO commands from rules. (Don’t forget a resistor to limit the current…)

Device Settings

  • Device Address: Select the desired device ID that the plugin should respond to. This requires the device to be enabled, and an iButton in contact with the receiver when opening the device settings page! When set, the task will only respond to this iButton ID, when read.

  • Event with iButton address: With this option enabled, and the Device Address selection left to - None -, instead of responding to a single iButton, an event is generated for any iButton that is recognized by the receiver. And once removed, the same event is generated without the iButton address. This can be processed in rules. See below in the Events chapter for a more detailed description.

Data Acquisition

This group of settings are standard available configuration items.

  • Single event with all values: When this setting is enabled, all available values will be sent in a single event <TaskName>#All, with all values in order as arguments to the event.

  • Show derived values: When checked, the Devices overview page, and the /json endpoint (used for updating the Devices overview page) will include any Derived values as defined. See the TaskValueSetDerived and TaskValueSetPresentation commands.

  • Event & Log derived values: When checked, the Derived values will be generated as Events, to be handled in Rules, and sent to logging devices like the Syslog server and/or SD-card logging.

(The derived values options are only available if String variables feature is included in the build.)


  • Send to Controller: Select the Controller(s) to send the Values to, either on a TaskRun command applied to the task, or on an Interval time action.

Send to Controller is only visible when one or more Controllers are configured.

Depending on the controller capabilities, some configuration settings may be shown:

../_images/Task_config_page_Controllers_section.png

All configured Controllers are shown here, including the enabled or disabled state (multiple Controllers can be enabled, only a single MQTT Controller can be enabled at one time!).

For each controller the user can select wether the data should be sent on each Interval (or explicit TaskRun).

For the Domoticz controllers the value index (IDX) has to be configured.

For some controllers, like Home Assistant/openHAB, there are extra options available.

  • Group: This represents the group id to combine all values from multiple tasks into a single grouped-device during MQTT AutoDiscovery. Groups, by design, can span multiple ESPEasy devices, if desired, as long as the Task/Valuename combinations are unique. If a group should only combine Tasks from a single ESPEasy unit, the group id should be unique across multiple ESPEasy units. The group description, default Group <n>, can be adjusted in Home Assistant. If the Group value matches the current Unit nr, the Unit name, %sysname%, is used instead of Group <nr>.

  • Retained: For MQTT Controllers, this setting can be enabled to send the values for the current task with the Retain flag set. The Publish Retain flag in the Controller settings will override this by sending all task values with Retain flag enabled.

  • Send derived: This checkbox determines if any configured Derived values should also be sent to the controller (and included in the AutoDiscovery if that’s available and enabled).

  • Resend MQTT Discovery: When checked, will start a resend of the MQTT Discovery process for this task after a random delay, when Submit is clicked, so any changed settings will be updated in the MQTT broker. This setting is only available if the controller is enabled, the Auto Discovery feature is available and enabled for the controller. This setting is not stored.

Other controllers, like f.e. FHEM HTTP, do not support additional settings besides the checkbox to enable sending the data.


  • Interval By default, Interval will be set to 0 sec. as it is optional. It is the frequency used to send the value to any Controllers configured for this device.

Values

The plugin provides the iButton value, that shows either 0 (no iButton on the receiver) or 1 (iButton recognized).

Events

Event

Example

<taskName>#Address=<state>[,<iButtonAddress_high>,<iButtonAddress_low>]

<state>: 0 or 1, depending on wether the iButton is on the receiver (1) or not (0).

<iButtonAddress_high>: The high 4 bytes of the (64 bit) iButton address in hexadecimal presentation, with a 0x prefix. The address parts are only included if the iButton is detected by the receiver.

<iButtonAddress_low>: The low 4 bytes of the iButton address in hexadecimal presentation.

This event is generated when the Event with iButton address setting is enabled, and no Device Address is selected (None).

As the iButton address is in fact a 64 bit value (though only 57 bits are used), this value is too large to be stored in a regular variable in the rules, so they are split into 2 parts, as often sets of iButtons are produced in the same batch, where the higher bits are the same, and only the lower bits vary.

These numbers can be processed, f.e. in a lookup table, similar to the example Validate a RFID tag against a sorted list (though somewhat different…)

Simply logging the data could look like this:

On iButton#Address Do
  Let,1,%eventvalue2%
  Let,2,%eventvalue3%
  LogEntry,'iButton %eventvalue2%_%eventvalue3% = %eventvalue1% (%v1% / %v2%)'
Endon

Change log

Changed in version 2.0: …

added 2024-05-10 Support for Event with iButton address.

added Major overhaul for 2.0 release.

Added in version 1.0: …

added Initial release version.