How to switch tasmota light bulb with HTTP

  • Platform information:
    • Hardware: Raspberry Pi 4
    • OS: Openhabian
    • Java Runtime Environment: 11.0.13
    • openHAB version: 3.1.0

I am currently getting started with OpenHab and am trying to control my Tasmota light bulbs via HTTP. While everyhing works fine when I use curl on my desktop, I cannot make it run with OpenHab.

I’ve configured my light bulb via the UI and got the following code for it:

UID: http:url:86e189c392
label: Lampe .30
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.178.30/
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
location: Wohnzimmer
channels:
  - id: OnOffSwitch
    channelTypeUID: http:switch
    label: OnOffSwitch
    description: ""
    configuration:
      onValue: ON
      stateExtension: /cm?cmnd=Power
      offValue: OFF
      commandExtension: /cm?cmnd=Power%2$s

As far as I understood it, the channel should make it possible that the state is sent to the light bulb. I added an item which made it possible to switch the channels value, however, no state change and no error appeared.

Can somebody give me a hint how to achieve this kind of configuration via OpenHab? Is there somewhere a documentation how to configure tasmota devices via OpenHab and http? So far, I only found examples with MQTT usage.

No, Item commands get processed for outgoing instructions.
That’s what you get if clicking openHAB UI - see your events.log
Command/state distinctions are important when it comes to bindings.

If you need further help, you’ll have to identify what HTTP message type and content you need to send.

Thanks for the quick reply!

I did not fully understand: If I click on the switch in the Item site of Lampe, I would like an outgoing instruction to be sent. As far as I understood the documentation, this should be configured via the commandExtension, or did I get this wrong?

In events.log, I get the following output:

2021-12-08 23:38:58.304 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Lampe’ received command ON
2021-12-08 23:38:58.308 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Lampe’ predicted to become ON
2021-12-08 23:38:58.316 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Lampe’ changed from OFF to ON
2021-12-08 23:39:09.663 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Lampe’ received command OFF
2021-12-08 23:39:09.667 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Lampe’ predicted to become OFF
2021-12-08 23:39:09.674 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Lampe’ changed from ON to OFF

Which in general seems fine to me, but the HTTP commands do not get sent.

The HTTP message type is get, for changing the state, I want to do the equivalent of curl 192.168.178.30/cm?cmnd=Power%20ON or curl 192.168.178.30/cm?cmnd=Power%20OFF, and for getting the state, I want to do a simple curl 192.168.178.30/cm?cmnd=Power, which returns something like {"POWER":"ON"}.

That’s right. Clicking in UI makes an Item command. If you talk about state, that is something different (usually incoming data from binding). Stuff gets in a middle if you confuse the terms.

That’s the important part, that will prod the binding.
If you have linked your Lampe Item to the http:url:86e189c392:OnOffSwitch channel, which you may have done at Item creation, or later.

Alright, so that’s an HTTP GET request?

This looks promising to start with.

That should give you
http://192.168.178.30//cm?cmnd=PowerON

I think you’ve got an extra / in there, and missed out the space before ON (just use space, as % has special meaning here)

Okay

Looks good, apart from extra / again

That’s JSON, so the conventional approach would be to install JSONPATH transformation add-on, and use the channel’s stateTransformation parameter to specify a JSONPATH for the POWER element.
Example in the binding docs.

1 Like

Why not use MQTT? It works very well for OH-to-Tasmota communication, which is why you’re only finding those as examples. I’m just asking out of curiousity.

Thanks a lot for the hints! Based on your hints, I was able to configure the light bulb as follows:

UID: http:url:86e189c392
label: Lampe .30
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.178.30/
  delay: 0
  stateMethod: GET
  refresh: 2
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
location: Wohnzimmer
channels:
  - id: OnOffSwitch30
    channelTypeUID: http:switch
    label: OnOffSwitch30
    description: null
    configuration:
      onValue: ON
      stateExtension: cm?cmnd=Power
      offValue: OFF
      commandExtension: cm?cmnd=Power %2$s
      stateTransformation: JSONPATH:$.POWER

With this configuration, I can successfully toggle my light bulb from the items page.

I currently only plan to configure a small count of light bulbs by OpenHab, which should allow setting different lighting. Therefore, running an additional server does not make sense to me - and since the MQTT server would run on the same Raspi, I think performance-wise this would also make no sense.

Why? If it is not handling traffic, it’s not doing much else.

As @rossko57 says, running MQTT has almost no impact on your server and you’ll never notice a performance drop due to it.

No harm in using HTTP now that you’ve got it working, though.

I assumed that at least running another server uses more RAM - but I did not research this in detail, I am just getting started with OpenHab.

However, configuring the light bulbs now nearly works for me.

Concerning the tasmota usage with HTTP, this is my nearly complete configuration for the things:

UID: http:url:86e189c392
label: Lampe .30
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.178.30/
  delay: 0
  stateMethod: GET
  refresh: 2
  commandMethod: GET
  timeout: 3000
  bufferSize: 2048
location: Wohnzimmer
channels:
  - id: OnOffSwitch30
    channelTypeUID: http:switch
    label: OnOffSwitch30
    description: null
    configuration:
      onValue: ON
      stateExtension: cm?cmnd=Power
      offValue: OFF
      commandExtension: cm?cmnd=Power %2$s
      stateTransformation: JSONPATH:$.POWER
  - id: Dimmer30
    channelTypeUID: http:dimmer
    label: Dimmer30
    description: ""
    configuration:
      onValue: "100.0"
      offValue: "0.0"
      stateExtension: cm?cmnd=Dimmer
      commandExtension: cm?cmnd=Dimmer %2$s
      stateTransformation: JSONPATH:$.Dimmer
  - id: Color30
    channelTypeUID: http:color
    label: Color30
    description: ""
    configuration:
      colorMode: HSB
      stateExtension: cm?cmnd=HSBColor
      commandExtension: cm?cmnd=HSBColor %2$s
      stateTransformation: JSONPATH:$.HSBColor
  - id: Lichttemperatur30
    channelTypeUID: http:number
    label: Lichttemperatur30
    description: ""
    configuration:
      stateExtension: cm?cmnd=CT
      stateTransformation: JSONPATH:$.CT
      commandExtension: cm?cmnd=CT %2$s

(which is copied 4 times, for light bulbs under the adresses .30, .31, .32 and .33) and linked to items for on/off, brightness, color and temperature, and the ui:

config:
  label: Overview
  layoutType: responsive
blocks:
  - component: oh-block
    config: {}
    slots:
      default:
        - component: oh-grid-cells
          config: {}
          slots:
            default:
              - component: oh-toggle-card
                config:
                  title: Wohnzimmerlampe an/aus
                  item: Wohnzimmerlampe
              - component: oh-cell
                config:
                  action: analyzer
                  actionAnalyzerItems:
                    - Wohnzimmerlampe
                  actionAnalyzerCoordSystem: time
                  trendItem: Wohnzimmerlampe
                  header: Lampe-Analyse
                  title: Lampe-Analyse
              - component: oh-slider-item
                config:
                  title: Dimmer Lampe1
                  item: WohnzimmerlampeHelligkeit
                  min: 0
                  max: 100
                  step: 1
              - component: oh-colorpicker-card
                config:
                  title: Farbe
                  item: WohnzimmerlampeFarbe
                  modules:
                    - wheel
              - component: oh-slider-item
                config:
                  title: Temperatur Lampe 1
                  item: Lichttemperatur
                  min: 153
                  max: 500
                  step: 1
masonry: []
grid: null

Setting on/off, changing brightness and color works nicely for all light bulbs. Unfortunately, setting the light temperature does not work as expected.

While setting the color temperature via for i in 30 31 32 33; do curl 192.168.178.$i/cm?cmnd=CT%20300; done works nicely, changing the slider results in the slider just jumping back to the original value.

events.log contains

2021-12-09 22:53:08.066 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Lichttemperatur' received command 386
2021-12-09 22:53:08.067 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Lichttemperatur' predicted to become 386
2021-12-09 22:53:08.072 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Lichttemperatur' changed from 300 to 386
2021-12-09 22:53:09.069 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Lichttemperatur' changed from 386 to 300

which indicates to me that it first changes to 386 and then changes to 300 back again.

Do you see any configuration which could lead to this problem?

EDIT I just wrote commandTransformation instead commandExtension. I fixed this and now it works fine. The above example can be used for HTTP tasmota configuration.

1 Like

Good stuff.

For future reference, many of us were running OH/MQTT on RPi 3s without any RAM issues. An RPi 4 with 2/4GB will easily handle the combo, and 8GB is considered overkill for a dedicated OH server.

You’re not wrong that it adds overhead, but if there was any concern you probably would have found a lot of posts about MQTT killing people’s servers. :wink:

My MQTT usage is pretty minimal: three Tasmota power strips, a 3D printer (via OctoPrint), and an Android app called SleepAsAndroid. Others have many, many devices on it.

1 Like