Need your help to publish an "special Mqtt" value (Smappee Power-Switch)

Configuration
1

Hi folks,

I try since hours to find a solution to toggle a Smappee power-switch via mqtt.
I am aware how to do directly via mqtt but find no solution how I could adapt to HA.
The topic has a timestamp in which must be calculated before. Here an expample of the neededtopic:

{ “value” : “ON”, “since” :“1549020444002”}

The timestamp should be not older the one minute.
I solved the generation of the timestamp with: as_timestamp(now())
In HA Template Editor this should work and I get the wanted output as a string:

*{“value”=“ON”, “since”="{{ as_timestamp(now())|int 1000 }}"}

Now the question how I could use this for an automation or best would be directly in mqtt switch entity?
I know how to send a mqtt topic from Automatization but the editor don’t accept all the brackets and “” that the string need. Any idea from the specialsts here?

2

What is the 1000 supposed to do? It results in an error in my template editor.

If the automation editor isn’t working for you, don’t use it.

3

No I could solve my issue but was a nightmare … I use now a input_boolean as a switch and send the mqtt topic with automation … as you mentioned … not possible with the editor because you have to use a data_template. Here how I did it:

  - data_template:
      payload: '{"value":"ON", "since":"{{as_timestamp(now()) |int*1000}}"}'

Timestamp delivers second and Smappee need milliseconds therefore I need a *1000
In addition a read the state of the power-plug via with a binary_sensor (platform: mqtt) and set the state after HA restart from the binary_sensor to the input_boolean to get a valid state.

image
image986×217 12.6 KB

4

Like I said, don’t use the editor then. You seem to be able to type in the forum, which means you can type in a yaml file.

The 1000 was confusing because you missed out the * in your first post.

1 Like
5

Sorry for the missing * in first post

6

Hi,

I’m Pieter, product manager at Smappee. I’m intrested in the usage of our MQTT topics and how we could improve our API.

One of the things we have on the improvement list is to make the timestamp an optional parameter. If you provide the timestamp it will be used to verify and give some additional protection that older messages that might be queued in the other system are not executed anymore. But if you want to have a straightforward implementation just send it without the ‘since’ timestamp and the message is always executed.

Other things that we could change / improve?

1 Like
7

@p.werbrouck : Hello Pieter , nice to meet you here. You support would be highly appreciated. I work only via Mqtt because I am not willing to pay a yearly fee for the usage of an API. The timestamp as an optional parameter would be good. Maybe it would be better to provide two new topics without the timestamp to avoid that someone how already implement Smappee with timestamp has the need to change something. The payload of the new power-plug topics (e.g. …/state_short & …/setstate_short) should be only “ON” and “OFF”. Here you can find the home assistant documentation for all Mqtt devices. The Mqtt switch can handle special states and payloads but if you have to calculate a current timestamp it can’t be do in this component directly and is very difficult to solve for beginners. Also a problem for me is to calculate all the values (see screenshot) every second. Unfortunately you support is until now not able to explain my exactly how the “aggregated” values working. Voltage and current is clear but averageRMSPower and so on are not clear and not well documented. It would be great if I could calculate the Ws and kWh with this values every minute and not every second. It increased my CPU utilization ~ 8% (Raspi Pi 3B+) only with my Smappee calculations and receiving so much Mqtt topics. Perfect solution for aggregated value would be a sum of Ws (or Wh) over one minute. (Sum of totalPower state for 60 sec. and send then the result as one topic). This would be a easy way to calculate the total power consumption of a day very 60 seconds what I have to do now every second. Overall I am satisfied and was able to solve all challenges with Smappee Energy. I learned a lot and the results are really impressive. Please take a look on the enclosed picture. The to cards with Smappee in the title shows what I did with the Mqtt topic and calculations. But all of this was only possible with all the incredible possibilities in home assistant. Best regards, Dirk

image
image1913×836 104 KB

8

@p.werbrouck
Hi Pieter, for me the biggest problem currently is that I have to sum every second the power vale to get an ws_total_today. I must save the value in a database to be able to restore after a restart of homeassistant. That results to that I have to write every second the value in the db. This leads in the high CPU utilization and will destroy every SD card in short time. Therfore the aggregated watt second value every minute would be the best improvement and most important from my point of view. BR Dirk

9

@p.werbrouck Would be great to make gas /water reading available by MQTT also. I think you’ll see a lot of backlash about having to pay for data that is actually our own through the API.
This isn’t the first time I’ve seen this happen, a product that is initially supported by the technically savy community, promoted, is then taken and monetised by it’s creators, locking out those very people that helped the product to become a success.

2 Likes
10

@Obicom, I do understand that you don’t want to pay a yearly fee for the cloud Rest API. I also hope you will understand that this cloud service has a cost for us. People / businesses that need historical data, data storage in our cloud, … should make use of the Rest API. If you’re interested in integration of Smappee data with home assistent, homekit, or oher smart home devices the way to go is the MQTT interface that is available on all electricity Smappee monitors.

Nice interface btw!

Plug topics (Smappee Switch and Comfort plugs):
I believe we can keep the existing topics, but just make the “since” an optional parameter. If we receive it we will use if, otherwise it is discarded. As such is compatible with existing implementations and we don’t have several topics for the same purpose.

Electricity data:
Aggregated data topic is available and publishes data every 5 minutes. Within Smappee we have as minimum interval 5 minutes. Changing this to 1 minute has an impact on the way we process data on the units, so would like to stick to the 5 minute interval. Ok?

Structure of the message could be improved and indeed documentation is not up to date. Will check with R&D how we can improve this. I believe we can already support what you need, but let me double check. (Person that has made the topics is currently on holiday, so could take a bit more time)

Gas & Water:
servicelocation//aggregatedGW is available with currently as payload:
{
“gwIntervalDatas”:[
{
“utcEndtime”:1516632900000,
“sensorId”:175,
“index0Delta”:2,
“index1Delta”:0,
“temperature”:246,
“humidity”:45,
“battLevel”:67,
“version”:1
}
]
}

Contains the consumption values aggregated per 5 minutes.

Note that this information is published on the 5 minutes boundary only if there was consumption during that 5 minute period.

Please note that the payload can still change. Not sure that we will keep the “gwIntervalDatas” as holder. This is useful to send data to the cloud and have multiple 5 minutes intervals in one message, but in the case of MQTT it will be 1 message each 5 minutes. Up to the MQTT listener to process the values.

Switch data:
servicelocation//aggregatedSwitch with as payload:

{
“switchIntervalDatas”:[
{
“utcEndtime”:1516632600000,
“activePower”:0,
“reactivePower”:0,
“version”:1,
“sensorId”:173
}
]
}

Please note that the payload can still change here, same remark as above.

11

Hi Pieter, First of all thank you for your reply. To the switch topic: This would be a good solution if timestamp would be optional. This would solve the problem also. About electricity data: I played around a lot with the values but I never got a result near to the real consumption. Maybe my gap of knowledge. Would be great if you could forward the question to the developer when he is back at work. Here I would propose to add a new and easy topic for average power consumption over 30 seconds, if possible. That would not change your need the 5 minutes aggregated topic and would bring a easy way to implement a valid and agile value for smarthome integrations. This topic should have the values for:

  averageVoltage
  averageCurrent_phase_1
  averageCurrent_phase_2
  averageCurrent_phase_3
  averageTotalPower_wh
  averageReactivePower_wh

as attributes of one topic:

servicelocation/uuid/average_30s

for example. If it would be possible to add this new topic (in 30 seconds regular updates) and timestamp for switch topic only as an option Smappee Energy mqtt solution would be perfect. Thank you in advance for your attention. About the best time frame (e.g. 10sec, 30sec, 60 sec) for the average topic should be discussed. Best regards, Dirk

12

@p.werbrouck
The support (Mathias) explains to me now how aggregated values work and it is exactly what I requested in my last post. But to be honest, a 5 minute value is for me to static … I would wish a little bit more agile value … not every second but 10 or 30 seconds would be perfect form my point of view. It would be “magic” if the user could set a time value for aggregated values in expert mode.

13

Yes this would be wonders!

14

I hope the Smappee developers/product managers will hear our demand and thing about …

15

I use the MQTT Switch to get the state off my Smappee actuator.

- platform: mqtt
    name: "Smappee mqtt Reserve 3"
    icon: mdi:power-socket-eu
    state_topic: "servicelocation/57xxxxcf-xxxx-xxxx-xxxx-0xxxxx6959f5/plug/1/state"
    command_topic: "servicelocation/57xxxxcf-xxxx-xxxx-xxxx-0xxxxx6959f5/plug/1/setstate"
    value_template: "{{ value_json.value }}"
    payload_on: "ON"
    payload_off: "OFF"

And I use a template switch to set the state of the actuator

  - platform: template
    switches:
      smappee_reserve_3:
        value_template: "{{ is_state('switch.smappee_mqtt_kreserve_3', 'on') }}"
        icon_template: mdi:power-socket-eu
        friendly_name: Reserve 3
        turn_on:
          - service: mqtt.publish
            data_template:
              topic: 'servicelocation/57xxxxcf-xxxx-xxxx-xxxx-0xxxxx6959f5/plug/1/setstate'
              payload_template: >
                  { 
                   "value" : "ON", 
                   "since" : {{ (as_timestamp(now()) * 1000) | round(0)}}
                  }
        turn_off:
          - service: mqtt.publish
            data_template:
              topic: 'servicelocation/57xxxxcf-xxxx-xxxx-xxxx-0xxxxx6959f5/plug/1/setstate'
              payload_template: >
                  { 
                   "value" : "OFF", 
                   "since" : {{ (as_timestamp(now()) * 1000) | round(0)}}
                  }
16

Good solution and show that much ways leads to Roma :wink: could you show a picture how it looks like in HA as a card? My solution is a input_boolean and binary_sensor … in addtion 2 automatization … one for switching and one for initial state after reboot/restart.

configuration.yaml

binary_sensor:
  - platform: mqtt
    state_topic: !secret smappee_state
    value_template: "{{value_json.value}}"
    json_attributes_topic: "{{value_json.since}}"
    name: "Steckdose Zustand"

input_boolean:
  smappee_switch:
    name: "Steckdose Schalten"
    initial: off
    icon: mdi:power-plug

automation.yaml:

- id: '1549051257454'
  alias: Smappee Plug Off
  trigger:
  - entity_id: input_boolean.smappee_switch
    platform: state
    to: 'off'
  condition: []
  action:
  - data_template:
      payload: '{"value":"OFF", "since":"{{as_timestamp(now()) |int*1000}}"}'
      qos: '2'
      retain: 'true'
      topic: servicelocation/xxxxx-xxxx-xxxx-xxxx-xxxxxxxx/plug/1/setstate
    service: mqtt.publish
- id: '1549052944604'
  alias: Smappee Plug On
  trigger:
  - entity_id: input_boolean.smappee_switch
    platform: state
    to: 'on'
  condition: []
  action:
  - data_template:
      payload: '{"value":"ON", "since":"{{as_timestamp(now()) |int*1000}}"}'
      qos: '2'
      retain: 'true'
      topic: servicelocation/xxxxx-xxxx-xxxx-xxxx-xxxxxxxx/plug/1/setstate
    service: mqtt.publish
- id: '1549054136699'
  alias: Smappee Plug Inital State
  trigger:
  - event: start
    platform: homeassistant
  condition:
  - condition: state
    entity_id: binary_sensor.steckdose_zustand
    state: 'on'
  action:
  - data:
      entity_id: input_boolean.smappee_switch
    service: input_boolean.turn_on

Visualisation:
image

17

afbeelding
afbeelding1125×2436 218 KB
afbeelding
afbeelding1125×2436 215 KB

18

I just use the template switch in my card…

19

I must say your solution looks nicer but I added a retain: true and qos: 1 to the topic to keep the value after reboot … it is a little bit a shame that it’t not possible to combine both parts from your example together in the mqtt switch component. Is there no way to create a data template or value template inside the mqtt switch for the state topic?

image

20

I don’t have any problems after a reboot → my Smappee state topic is retained

05
051800×326 23 KB

Is there no way to create a data template or value template inside the mqtt switch for the state topic?

I’ve spend a whole day to try this out …