As I am still learning I will do both!
Which brings me to say thank you so much for your instruction and your patience. I’ll do you second suggestion first as I have already setup usage part of the sensor.
1 Like
I found the binary_sensor in the list of integrations but can’t seem to create a switch.
why, what’s happening. did you add the config I showed you to the switch domain under:
switch:
- platform: template
switches:
and if yes, any errors (I take it you have the used shell_commands and the sensor for the template in order?)
read up on template switches here
Hi Marius,
Sorry for my late reply. I had to do some work in between fiddling with HA. Also I tried and re-tried some stuff in HA but I fear I’m I have either a reading or writing error some where.
Where it stands now is that the shell commands work. I have one for on and one for off. When using these in terminal they work perfectly. The template switch and the binary sensor method I both can’t get going.
switch:
- platform: template
switches:
licht_keuken:
friendly_name: Licht Keuken
value_template: "{{ is_state('sensor.licht_keuken', 'on') }}"
turn_on:
service: switch.turn_on
data:
entity_id: shell_command.licht_keuken_on
turn_off:
service: switch.turn_off
data:
entity_id: shell_command.licht_keuken_off
shell_command:
licht_keuken_on: curl -X POST -d '{“seq”:1,etc etc etc
licht_keuken_off: curl -X POST -d '{“seq”:1,etc etc etc
Dunno if you could see anything in there that doesn’t fly?
As far as error logs go, HA is not returning any errors. The template of the switch is created and it has a toggle but that is in off. When switched to on it switches back to off.
not sure, but with template switches not working properly most of the time then issue is in the template. the behavior you describe seems to point in that direction.
can you check if that is really correct?
you can do so by entering the template in the template editor, and then call the shell commands to toggle the switch
also, your services are not as in my post , please check carefully how I did it
turn_on:
service: shell_command.test_library_on
and not:
turn_on:
service: switch.turn_on
data:
entity_id: shell_command.licht_keuken_on
Your right the services were not as in your post. I think I copied those from the link to the template instruction you posted.
I looked at this in the template editor. and it came back with only text.
The code below is all that has to do with the “keuken licht” z-wave plug 
the sensor and binary sensor are working fine I get the wattage of the sensor and and the state of the binary sensor. Which correctly says that it is on or off.
shell_command:
licht_keuken_on: curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"25b1fa26", "prop":"command", "value":"on"}}' http://192.168.178.41/iungo/api_request
licht_keuken_off: curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"25b1fa26", "prop":"command", "value":"off"}}' http://192.168.178.41/iungo/api_request
switch:
- platform: template
switches:
licht_keuken:
friendly_name: Licht Keuken
value_template: "{{ is_state('sensor.licht_keuken', 'on') }}"
turn_on:
service: shell_command.licht_keuken_on
turn_off:
service: shell_command.licht_keuken_off
sensor:
- platform: mqtt
state_topic: '11:22:33:44:55:66/powerswitch-zwave/25b1fa26/usage'
unit_of_measurement: watt
name: Licht keuken
binary_sensor:
- platform: mqtt
name: Licht Keuken
state_topic: '11:22:33:44:55:66/powerswitch-zwave/25b1fa26/state'
payload_on: 'on'
payload_off: 'off'
the shell commands work in the services section of developer tools
not sure what you’re saying here, but if you enter
{{ is_state('sensor.licht_keuken', 'on') }}
into the template editor is should return ‘True’ or ‘False’
if not, the template or the entity is not right.
o, wait! your sensor is not for state, it is for usage… that’s why it will always return ‘False’, because it is never ‘on’ but has a numeric value for usage…
you should use the binary_sensor in the template then, even better.
{{is_state('binary_sensor.licht_keuken','on')}}
fwiw, you can also create a mqtt sensor for state
- platform: mqtt
state_topic: 'iungo-macaddress/powerswitch-zwave/oid/state'
name: Test Library state
force_update: true
but, since you have a working binary_sensor for that same topic, you can leave it at that, and use the binary
indeed it does return true and false depending on the state.
Meanwhile I have gotten a button in lovelace to switch it off with the shell command but i’m not able to see it as a toggle yet
it’s like a puzzle with infinite pieces 
ok for now I have it working with a “button” in Lovelace.
Tap switches the light on
Hold switch the light off
Ideally though i’d like to have that in a toggle 
Don’t ask me how but I got it sorted!! ?? toggle switch is working
simply use the service switch.toggle on the button will do that. And yes, it’s always a puzzle.
But, best to always start with the backend (create sensors, setup mqtt, define shell_commands etc etc) and then, if everything is working correctly, start building the frontend.
I take that too in steps: first use a core entities card to see if everything you created in the backend shows and works in the frontend.
If yes, then start making that appear as you wish, using customizations, or specific (custom)-cards.
glad you got it sorted for now.
I’m glad too. Super thanks for your help and patience.
I’m almost afraid to ask but do you incorporate any other niceties from iungo into HA like maybe the history in excel and such?
nope. only use the Iungo as a source for data. Id suggest having a look at the well documented Grafana/InfluxDB for manipulating your history.
What can be of additional value is the basic Buienradar config from Iungo. That is always available, while experience with the buienradar integration in core HA isn’t that rock solid.
also, for all data, Iungo creates a daystart sensor, so if you are interested in power consumption on a daily base, you can use these.
if you configure the MQTT explorer, you will see which topics are published, and you can create sensors for those in HA easily.
today Iungo will update a beta version of the firmware which should make stability better, and maybe offer new functionality (not sure).
be sure to check that out.
Yep I saw a bunch of data come out the MQTT explorer. So Ill fiddle around a bit with that in time.
I’ve been playing with HA now for about two weeks running it of a RASP PI and I am simply blown away by the extent of possibilities. As well as the assistance from and size of the community here.
And to think that this is the beginning of smart home technology, quite extraordinary.
I have a shelly 2,5 coming in today to see how and if I can integrate those in to the house as well as aqara temp sensor that I received yesterday which works like a charm.
Amazing
HI Marius,
A bit off topic, I tried the InfluxDB but can’t get it to work. Apperently that has to do with some of the security settings.
On the positive side the Buien radar does work and the lights also still do.
Hi,
I am an iungo user ( 5 years ) and since a few months also Home Assistant. ( Green device ).
I checked the IP-adress/iungo/control? Data,
But…
No option to fill in my MTQQ broker .
iungo software: versie 1.5 Revisie: 4450 . Datum: 07Dec23.
Could it be possible that iungo has blocked this MTQQ option in the control page ?
Not here . All fine.
Is the mqtt section completely gone or cant you just fill in the details?
I had a terrible experience updating though and my controller was completely reset…
Rodney managed to bring back the backup though.
Could it be you need to be registered as beta user?
Best contact them if you can enable.
Hi Johan, just figuring this out today as you did recently.
I found that you can make the MTQQ broker ‘show up’ by following the instruction in the first post here:
In case the link changes again, I will cite it here as well:
"MQTT
Voor beta gebruikers, control?cmd=api_form&method=objmgr_add_object
Bij driver bus-mqtt invullen (uid leeg laten)
Vul op control driver pagina het juiste MQTT broker (server) adres in (bijvoorbeeld mqtt.thingstud.io)
Alle events vanuit iungo worden doorgestuurd naar de MQTT broker met de volgende topic strucuur
topic: ///
Het Mac adress is te vinden achter op iungo
Het type object is het eerste stukje van de driver naam, het object id is het gedeelte van de drivernaam tussen de blokhaken.
De property kan eventueel bekeken worden op /iungo/app/#/log, de waarden die hier vermeld worden zullen ook naar de MQTT server verstuurd worden.
You still need to be registered as beta user at Iungo.
1 email to the dev team there should fix that