Switching a go-eCharger between 1phase and 3phase mode

Hi there!
I try to bind in the go e charger in my openhab system… The existing binding gives access to most important values but one missing: to be able to switch from 1 to 3 phase mode.

I managed to get the value changed via MQTT:
mosquitto_pub -t “/go-eCharger/071212/psm/set” “1” → 1phase mode
mosquitto_pub -t “/go-eCharger/071212/psm/set” “2” → 3phase mode

but trying to define this as a switch channel doesn’t want to work:

UID: mqtt:topic:MQTT_Broker_Bridge:GoE_MQTT
label: GoE_MQTT
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:MQTT_Broker_Bridge
  - id: GoeMqttPSM
    channelTypeUID: mqtt:switch
    label: GoeMqttPSM
    description: ""
      commandTopic: go-eCharger/070202/psm/set
      stateTopic: go-eCharger/070202/psm
      off: -m "1"
      on: -m "2"

Also http commands work: → 1 phase mode → 3 phase mode
I initiated a http-Thing, but don’t get this configured correctly either…

Anyone who can help?
Thanks Ansgar

1 Like

What’s the -m about?

Hi Rossko,
the original mqtt-sequence is:
mosquitto_pub -t "/go-eCharger/070202/psm/set" -m "2"
that sequence is tested and working in an ssh-window.
I also stumbled over the quesition where to put the “-m” and tried both, also the version to add it in the command topic:

      commandTopic: go-eCharger/070202/psm/set -m
      stateTopic: go-eCharger/070202/psm
      off: "1"
      on: "2"

… also without success.
the -m tells mosquitto to send a payload:

 mosquitto_pub --help:
-m : message payload to send.

Yes. (Well, the utility mosquitto_pub really)
The actual payload is 2

openHAB is not mosquitto_pub and thinks -m is part of the payload.

off: 1
on: 2

You can use mosquitto_sub to find out exactly what you have configured openHAB to send.

Thanks Rossko,
so I skipped the “-m” and configuration now looks as follows:

      commandTopic: go-eCharger/070202/psm/set
      postCommand: false
      stateTopic: go-eCharger/070202/status
      off: "1"
      on: "2"

the “” around “1” and “2” are set by openhab. In UI it looks like :

But: the go-echarger doesn’t react on the switch item linked to my new channel :frowning:


What are you doing to the Item? You must send a command to Item to get the binding to do its sending. UI clicking should do, check your events.log

I did so. Using:
openhabian@openhabian:~ $ mosquitto_pub -t "/go-eCharger/071212/psm/set" -m "1" openhabian@openhabian:~ $ mosquitto_pub -t "/go-eCharger/071212/psm/set" -m "2"
I do get the answers:

openhabian@openhabian:~ $ mosquitto_sub -v -t '/go-eCharger/#' | grep -P '/(?:psm|fsp) '
/go-eCharger/070202/fsp false
/go-eCharger/070202/psm 2
/go-eCharger/070202/fsp true
/go-eCharger/070202/psm 1
/go-eCharger/070202/fsp false
/go-eCharger/070202/psm 2

So this way I can see comfortably if the go-e receives my commands and reacts correctly.

following this tip I could find out my openhab system sends “on” and “off” instead of the “1” and “2” awaited from the go-e charger:

2021-12-10 13:45:47.725 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoEMQTT_GoeMqttPSM' received command OFF

2021-12-10 13:45:47.727 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoEMQTT_GoeMqttPSM' predicted to become OFF

2021-12-10 13:45:47.735 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoEMQTT_GoeMqttPSM' changed from ON to OFF

2021-12-10 13:45:47.995 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoEMQTT_GoeMqttPSM' received command ON

2021-12-10 13:45:47.996 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoEMQTT_GoeMqttPSM' predicted to become ON

2021-12-10 13:45:48.002 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoEMQTT_GoeMqttPSM' changed from OFF to ON

I seem to be wrong with the idea that after defining

a switch item being linked to this channel would send a 2 instead of “On” and a 1 instead of “Off” !?

That’s not what that means. Every switch Item in openHAB uses ON/OFF commands internally. That’s the whole idea, all Items look alike and behave the same no matter what they’re linked to.

It’s the job of the channel and binding to turn a standard ON into a TCP message with some MQTT topic and payload “banana” or whatever it is you need. You don’t see that in openHAB’s internal log.

So Item command ON is just what we want to see internally.

Now, what does mosquitto_sub tell you is sent out by openHAB at the time of the command?

nothing, unfortunately.
I opened two ssh windows.

in one I start the observation:

openhabian@openhabian:~ $ mosquitto_sub -v -t '/go-eCharger/#' | grep -P '/(?:psm|fsp) '

The second I use to fire commands on mqtt-level, e.g.:

openhabian@openhabian:~ $ mosquitto_pub -t "/go-eCharger/070202/psm/set"  -m "1"

that works as expected and I find the appropriate reactions in the mosquitto_sub-window.

if I try to fire the commands from my switch that is linked to the mqtt-channel nothing happens in the mosquitto_sub-window :frowning:

I already tried to translate the On/Off commands from the switch-item by use of a rule that’s triggered if the switch-state changes:

//dieses Programm übersetzt die Schalterstellungen von GoE_3Ph_Switch von On auf 2 bzw. Off auf 1
if (GoE_3Ph_Switch.state == ON)

the appropriate log.items are:

2021-12-10 14:25:13.492 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoE_3Ph_Switch' received command ON

2021-12-10 14:25:13.496 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoE_3Ph_Switch' changed from OFF to ON

2021-12-10 14:25:13.502 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoEMQTT_GoeMqttPSM' received command 2

2021-12-10 14:25:13.503 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoEMQTT_GoeMqttPSM' predicted to become 2

2021-12-10 14:25:13.505 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoEMQTT_GoeMqttPSM' changed from 1 to 2

2021-12-10 14:25:13.662 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoE_3Ph_Switch' received command OFF

2021-12-10 14:25:13.663 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoE_3Ph_Switch' changed from ON to OFF

2021-12-10 14:25:13.835 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoE_3Ph_Switch' received command ON

2021-12-10 14:25:13.837 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GoE_3Ph_Switch' changed from OFF to ON

2021-12-10 14:25:13.934 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'GoEMQTT_GoeMqttPSM' received command 2

2021-12-10 14:25:13.935 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'GoEMQTT_GoeMqttPSM' predicted to become 2

but still - although the number-item “GoEMQTT_GoeMqttPSM” changes from 1 to 2 and vice versa, no entry is found in the mosquitto-sub window and consequently the go-e charger doesn’t react…

Okay, not much point fiddling with payload translations then.
Review your commandTopic carefully.
I can see you’re not consistent about it having a / at the beginning.

Make sure the Item getting commands is linked to your switch type channel.

Any reason why it should? You’ve not mentioned linking that Item in any way to MQTT, or creating a new number channel.

Yes, of course the following chain is available:
a mqtt-broker (mosquitto) is running on the raspberry py
a bridge-thing builds the connection to this broker and is used for several connections
a MQTT-Thing called “GoE_MQTT” using the bridge above
this Thing has a (number-) channel defining the command channel go-eCharger/070202/psm/set (btw: all other working mqtt-channels for other (tasmota-) things start without a leading “/”)
the item “GoEMQTT_GoeMqttPSM” is linked to the channel.
the item’s value is changed via rule from 1 to 2 and vice versa depending on a switch item (GoE_3Ph_Switch).
I assumed this chain will trigger a mqtt-message each time the value changes!??

No, MQTT messages are only sent if an Item gets a command.
If you do not keep clear in your mind that commands are not states, you will get in a mess.

I couldn’t comment on the rest of the chain without details - the thing about chains is that any broken link stops the whole thing working.

Perhaps you overlooked -

This channel configuration -

is not the same topic as you are listening to

so whether openHAB sends anything or not, you do not know.

If you use mosquitto_pub to transmit a message without the leading /, does it work?
If not, then openHAB won’t work either.

Hi Rossko,
thank you very much for your patiance and the detailed comments on my postings.

… I change the state of the item with the following command in my rule:


Assuming the Item “GoEMQTT_GoeMqttPSM” is properly linked to the mqtt-channel, can’t I expect this to trigger the appropriate mqtt-message?

I copied this syntax (without leading /) from other mqtt-connected things (Tasmota/sonoff).
I found out that tasmota doesn’t require a leading “/” but go-e does!
In any case you are right: syntax needs to be identical for mosquitto and in channel definition.

short answer: No for the go-e charger.
long answer: I tried both; with and without leading “/”. Reflecting the results from above and knowing in mosquitto-pub commands for go-e only work with leading “/” I will define the channel with leading “/” .

Although this all enhance my knowledge I still didn’t succeed to get the command working :frowning:

Any further idea?

Well, after all this fiddling about, let us see what you have now…
Note that bindings can get in a mess with repeated edits and type changes, so I would recommend a reboot once you have everything - thing, channel, link, Item - as you want it.

I got a step forward:
I added a http-type thing pointing on the ip of my go-e

Next step I added a string type channel to this thing and defined the advanced settings for:
State URL Extension = “/status”
Command URL Extension = “/mqtt?payload=fsp=%2$s”

Finally, I added a Switch type link to the item above.
That works and is able to switch between 3phase and 1phase mode.
But problem here is in seems to forget its state and falls back to “UNDEF” after 30s.
I assume a problem with my definition to request a status ( “/status”) but don’t have deeper knowledge for proper definition to refresh the status corectly and regularly !???

When you are ready, show us what you have.

Dear all who want to see what I have:
I got it working to generate an item that allows me to control if the go-e charger charges on single or 3 phases:
for all others than phase control I simply use the existing binding for the go-e charger.
for phase control I defined a http-binding with the following code:

UID: http:url:GoE_http
label: GoE_http
thingTypeUID: http:url
  authMode: BASIC
  ignoreSSLErrors: false
  delay: 0
  stateMethod: GET
  refresh: 30
  commandMethod: GET
  contentType: application/json
  timeout: 3000
  bufferSize: 2048
  - id: GoE_http_fsp
    channelTypeUID: http:string
    label: GoE_http_fsp
    description: ""
      onValue: "1"
      offValue: "0"
      stateExtension: /status
      commandExtension: /mqtt?payload=fsp=%2$s
  - id: GoE_http_psm
    channelTypeUID: http:switch
    label: GoE_http_psm
    description: null
      onValue: "2"
      offValue: "1"
      stateExtension: api/set?psm=%2$
      commandExtension: api/set?psm=%3
  - id: GoE_http_amp
    channelTypeUID: http:number
    label: GoE_http_amp
    description: ""
      stateExtension: /status
      commandExtension: /mqtt?payload=amp=%2$s

I’m happy if I could help anybody here…