Error With Node-REC Service Call to OpenEPaperLink

[Boh1]

I'm running into an issue with OpenEPaperLink and Node-RED.

When attempting to issue a service call to a pre-existing tag, I'm consistently seeing the following debug error in Node-RED:

Call-service error. id was not found yet, please wait for the display to check in at least once

Looking at the underlying HA logs, it seems there's a websocket error underlying this behaviour:

Logger: homeassistant.components.websocket_api.http.connection Source: components/websocket_api/commands.py:238 Integration: Home Assistant WebSocket API (documentation, issues) First occurred: 2:35:42 PM (12 occurrences) Last logged: 4:21:15 PM

[139738574304960] id was not found yet, please wait for the display to check in at least once Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 238, in handle_call_service response = await hass.services.async_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2067, in async_call response_data = await coro ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2104, in _execute_service return await target(service_call) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/open_epaper_link/init.py", line 38, in drawcustomservice imgbuff = await hass.async_add_executor_job(customimage,entity_id, service, hass) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/open_epaper_link/imagegen.py", line 112, in customimage raise HomeAssistantError("id was not found yet, please wait for the display to check in at least once") homeassistant.exceptions.HomeAssistantError: id was not found yet, please wait for the display to check in at least once

However, if I do the same service call, to the same tag using the Developer/Services tool, everything works as expected. I've tried multiple reboots of HA and different tags.

I have also tested this with both the lines4 and drawcustom services with the same results. An example of what Node-RED is sending in the service call (4 line example) follows:

This looks correctly formatted to me, but clearly something is happening that is failing. Do you have any suggested debug paths?

[jonasniesner]

Have you tried the request directly in HA?

[Boh1]

Yes. That's what I meant by this part of my bug report:

However, if I do the same service call, to the same tag using the Developer/Services tool, everything works as expected.

Apologies if that wasn't clear.

Home Assistant 2023.12.4, Node-RED v3.1.0 and OpenEPaperLink 0.4.4 .

[jonasniesner]

Sorry, did not read that. I don't really have any experience in node red to home assistant service calls. the device id does not look like it belongs there. I will include something in the next update that gives more debug info

[jonasniesner]

Can you send me the same picture of the 4 line service call with the newest release? This should help us narrow down the issue

[Boh1]

Do you mean the latest release of Home Assistant?

[jonasniesner]

No, the integration

[Boh1]

Same 4 line test, this time with Version 0.4.5. I tried it both with and without the device ID specified - same error. Here's what's being sent without the DeviceID being specified:

[Boh1]

Corresponding HA log for the above test:

Logger: homeassistant.components.websocket_api.http.connection Source: components/websocket_api/commands.py:238 Integration: Home Assistant WebSocket API (documentation, issues) First occurred: 1:55:19 PM (4 occurrences) Last logged: 2:02:28 PM

[140422009935424] id was not found yet, please wait for the display to check in at least once o Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 238, in handle_call_service response = await hass.services.async_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2067, in async_call response_data = await coro ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2104, in _execute_service return await target(service_call) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/open_epaper_link/init.py", line 73, in lines4service imgbuff = gen4line(entity_id, service, hass) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/open_epaper_link/imagegen.py", line 569, in gen4line raise HomeAssistantError("id was not found yet, please wait for the display to check in at least once " + entity_id) homeassistant.exceptions.HomeAssistantError: id was not found yet, please wait for the display to check in at least once o

[jonasniesner]

I see the error now, you put the entity id in the wrong place, the integration only gets an o ad entity

[jonasniesner]

The entity id does not belong into the data service: open_epaper_link.lines4 data: line1: Test line2: waylongertext line3: Test Text line4: left border: r format1: mbbw format2: mwwb format3: mbbw format4: lrwb target: entity_id: open_epaper_link.000001810e653b3e

[Boh1]

I don't understand your comment. Let me break this down.

This is the data that I specified to be sent in the payload:

{ "line1": "Test", "line2": "waylongertext", "line3": "Test Text", "line4": "left", "border": "r", "format1": "mbbw", "format2": "mwwb", "format3": "mbbw", "format4": "lrwb" }

There's no Entity ID in that payload, just data,

But the Call Service node in Node-RED needs an Entity ID as a target, which looks like this:

The debug message I screen captured reflects what the Call Service Node is actually sending with this configuration. In theory, it should be exactly the same as using the Developer / Call Service template. But it clearly is not, since it errors out.

If this is something that can't be fixed, cool. I will figure out a way to see if I can make this work by building the entire call in JavaScript and then using a web-hook. Old school, but it might get around whatever issue exists with the OpenEPaperLink and Node-RED.