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:
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:
configuration:
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.
...
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:
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
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?
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
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)
{
GoEMQTT_GoeMqttPSM.sendCommand(2)
}
else
{
GoEMQTT_GoeMqttPSM.sendCommand(1)
}
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!??
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:
GoEMQTT_GoeMqttPSM.sendCommand(2)
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
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.
Hello
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 !???
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: