Hello, it works perfect with the new OpenATV 8.0.0
Thanks
Edit:
Do you know a smart dashboard Card to program or control the Enigma receiver?
tile card ¿? entity: media_player.XXXXX
type: tile
grid_options:
columns: 12
rows: auto
entity: media_player.XXXXX
name:
type: entity
state_content: media_title
vertical: false
features:
- type: media-player-playback
- type: media-player-source
- type: media-player-volume-slider
features_position: bottom
Thank you.
Best regards.
I’ve installed the plug in on an old zgemma h2s (open atv 7.6) and integration in home assistant - Within the integration the value against each control is in a constant loop between unavailable and the value of the control. The zgemma box has also slowed to a standstill. Mosquitto broker is also showing disconnected: oversize packet.
Thanks all for testing and for taking the time to report back - this is exactly the feedback I was hoping for.
@DelBierzo - great to hear, and thanks for the detailed list. GigaBlue UHD IP 4K, UHD Trio 4K and UHD UE 4K on OpenATV 7.6 go into the compatibility table. One question: you added the feed by hand over PuTTY - did you try the guided installer in the integration (it installs the plugin from Home Assistant over the network), or did you not notice it was there? If it failed or was unclear, I would like to know.
@MartyBr - thanks, OpenATV 8.0.0 is noted as working too. On the card: the tile card DelBierzo posted is the simplest option today. There is no dedicated card yet. If you could describe what you would want on it (channel list with picons, now/next EPG, a remote, timers/recordings?), that would help me decide what to build first.
@stepea - thank you for reporting this, it is a bug in the plugin and not a problem with your box. Mosquitto 2.1 (the current Home Assistant add-on) disconnects any client that sends a packet over 2 MB. By default the plugin publishes the complete channel list of every bouquet, plus an EPG grid per bouquet, and with a large settings list that goes over the limit. The broker drops the receiver, it reconnects, sends the same data again, and that is the unavailable/available loop you see. Rebuilding that list on every round is also what slows the box down.
Workaround until the fix is out: in the MQTT Bridge setup on the receiver, limit the bouquets to the few you actually use (comma-separated bouquet names) and set the EPG grid events to 0, then restart the GUI.
To confirm it, could you tell me:
- roughly how many bouquets and channels the box has (and which settings list, if it is a ready-made one),
- the lines around “oversize packet” from the Mosquitto add-on log.
The next release will stop the plugin from ever sending a packet the broker would reject, and will publish the channel list per bouquet instead of in one message.
**For everyone running it**, a few things that would help me make it better:
- Receiver model, image and version - also if it simply works, so the compatibility list grows.
- How it behaves on older or slower boxes: any lag in the menus, zapping, or GUI start since installing the plugin?
- Which entities and actions you actually use, and which you switched off.
- What is missing for your automations or dashboard.
- Anything in the setup, on the receiver or in Home Assistant, that was confusing or needed a second attempt.
Bugs are easiest for me to track as a GitHub issue on the plugin or the integration repository, but a reply here is fine too.
Did the workaround to one bouquet and it works fine - I haven’t got round to sorting out the bouquets on the box, most need deleting.
@stepea thanks for confirming - that settles the cause: with every bouquet selected the channel list was bigger than the broker accepts in one message.
No need to tidy the bouquets for this. The next release (0.5.0) stops the plugin from ever sending a message the broker would reject, and publishes the channel list per bouquet instead of in one piece, so a receiver with many bouquets works without the workaround. Until then, keep the one-bouquet setting.
If you have a minute: roughly how many bouquets and channels are on the box? It helps me test with realistic sizes.
Yes, the option to install it from the add-on itself is available, but I preferred to do it manually.
Regarding crashes, lag, or any other issues, I haven’t noticed any so far.
You could include the picons and send notifications.
For example, using notifications from the Cinzas app: I have an automation where, depending on the time I go to bed, the presence sensor turns on the TV and starts a sleep timer (displaying a notification on the screen that the TV will turn off in *x* minutes). When there is one minute left before it shuts off, it notifies me again, allowing me to either cancel it or add more time. Having the ability to send notifications would be excellent.
command_line:
- switch:
name: bedtime_enigma_notify
command_on: 'curl -k -s "http://192.168.1.5/web/message?text=BEDTIME&type=1&timeout=10"'
You can create a command to send messages http to enigms
@DelBierzo thanks, good to hear it runs clean - and manual install is fine, the installer is only a convenience.
Both of those are already in there:
Notifications. The receiver gets two notify entities: a popup, and a discreet toast in a corner that needs no key press and hides itself (the toast appears only if the receiver supports it). For control over the timeout use the enigma2_mqtt.message action:
action: enigma2_mqtt.message
target:
entity_id: media_player.your_receiver
data:
text: "TV turns off in 1 minute. Green = +15 min, red = cancel"
style: popup # or toast
type: info # info / warning / error
timeout: 30
Picons. The media browser shows the box’s own picons per channel, and the media player card shows the picon of the current channel. They are fetched from the receiver’s OpenWebif, so they appear only if picons are installed on the box and HA can reach it over HTTP.
Cancel / add time from the remote. You can do this today: the colour keys are device triggers (red / green / yellow / blue, short and long press). Send the message as a popup and trigger on the key while it is open. I tried it here: with the popup on screen HA gets the key and the receiver does not run its own function for it. With a toast the receiver reacts to the key as well, so use the popup for this. The popup stays until its timeout or OK/EXIT, so let the automation listen only for that long.
Here is the pattern as an automation. The plugin fires an enigma2_mqtt_key event for every key, with key and press in the event data, so a wait_for_trigger right after the popup catches the answer:
alias: Bedtime - TV off with a warning
triggers:
- trigger: state # replace with your own bedtime trigger
entity_id: input_boolean.bedtime
to: "on"
actions:
- repeat:
sequence:
- action: enigma2_mqtt.message
target:
entity_id: media_player.your_receiver
data:
text: "TV turns off in 1 minute. Green = +15 min, red = cancel"
style: popup
timeout: 30
- wait_for_trigger:
- trigger: event
id: more
event_type: enigma2_mqtt_key
event_data:
key: KEY_GREEN
press: short
- trigger: event
id: cancel
event_type: enigma2_mqtt_key
event_data:
key: KEY_RED
press: short
timeout: "00:00:30"
- if: "{{ wait.trigger is not none and wait.trigger.id == 'more' }}"
then:
- delay: "00:15:00"
until: "{{ wait.trigger is none or wait.trigger.id != 'more' }}"
- if: "{{ wait.trigger is none }}"
then:
- action: media_player.turn_off
target:
entity_id: media_player.your_receiver
Green adds 15 minutes and asks again, red ends it and leaves the TV on, and no answer within 30 seconds puts the receiver into standby. The wait has the same length as the popup, so a colour key pressed later is just a normal key press. With more than one receiver, add device_id to event_data. The same keys are also available as device triggers in the automation editor if you prefer clicking it together.
A proper question you answer from the remote, with the answer sent back to HA, is planned for 0.5.0.
@Spiro right, that works with OpenWebif 
