V1.7: Error messages in Service status

[fu-zhou]

I installed V1.7, MQTT communication with the server works however the following error messages are shown in systemctl status essmqtt:

● essmqtt.service - ESS MQTT Communication
   Loaded: loaded (/etc/systemd/system/essmqtt.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-05-30 19:05:05 CEST; 2min 40s ago
 Main PID: 126215 (essmqtt)
    Tasks: 1 (limit: 2290)
   CGroup: /system.slice/essmqtt.service
           └─126215 /home/user/essmqtt/bin/python3 /home/user/essmqtt/bin/essmqtt --mqtt_server 192.168.0.50 --ess_passwor

May 30 19:07:43 iobroker-vm essmqtt[126215]: ERROR:pyess.essmqtt:exception while sending to mqtt
May 30 19:07:43 iobroker-vm essmqtt[126215]: Traceback (most recent call last):
May 30 19:07:43 iobroker-vm essmqtt[126215]:   File "/home/user/essmqtt/lib/python3.8/site-packages/pyess/essmqtt.py", lin
May 30 19:07:43 iobroker-vm essmqtt[126215]:     await mqtt_client.publish("ess/home/" + key + "/" + key2, home[key][key2]
May 30 19:07:43 iobroker-vm essmqtt[126215]: TypeError: string indices must be integers
May 30 19:07:45 iobroker-vm essmqtt[126215]: ERROR:pyess.essmqtt:exception while sending to mqtt
May 30 19:07:45 iobroker-vm essmqtt[126215]: Traceback (most recent call last):
May 30 19:07:45 iobroker-vm essmqtt[126215]:   File "/home/user/essmqtt/lib/python3.8/site-packages/pyess/essmqtt.py", lin
May 30 19:07:45 iobroker-vm essmqtt[126215]:     await mqtt_client.publish("ess/home/" + key + "/" + key2, home[key][key2]
May 30 19:07:45 iobroker-vm essmqtt[126215]: TypeError: string indices must be integers

everytime I look into the status, the errors have the current time stamp, i.e. it seems as if the errors occur continously.
From what I understood the config file is optional, I can still work with the command line, right?

[gluap]

@fu-zhou yes you can still work with the command line!
Actually I guess this is not even a new issue - It is one of the locations where I added extra logging in order to find out whether they cause #7.

I'll look into it, pretty sure it can be fixed quickly.

[fu-zhou]

Ah, okay, the additional logging then idientified the two issues:
TypeError: string indices must be integers
ERROR:pyess.essmqtt:exception while sending to mqtt

The ERROR is maybe a result of the TypeError?

[gluap]

@fu-zhou yes, the full multiline message is the result of the same TypeError - the logging I added displays all the lines together. I was hoping to find the cause for the hangups this way, by also displaying the stacktrace. The issue debugging is that with asyncio it easily happens that one does not notice that an exception happens somewhere unless it is caught explicitly. My guess was that the mqtt send loop was crashing without saying good bye so I added logging therein. That logging indeed exposed an issue on your end (but not #7).

0.1.8 should fix this new issue as far as I can tell. The error you describe above does not happen on my ess, likely because the structure of /home/ and /common/ daata sources differs between our ESSes.

I know about the potentially appearing new log message

INFO:pyess.aio_ess:fetching auth key
 /home/pi/pyess/venv/lib/python3.7/site-packages/aiohttp-4.0.0a1-py3.7-linux-aarch64.egg/aiohttp/client.py:977: RuntimeWarning: coroutine 'noop' was never awaited
   self._resp.release()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

If it appears on your end that should not be a cause for concern -- it is a bug in aiohttp that will likely be fixed in a future version of their package, but that shouldn't cause issues apart from displaying the message.

[fu-zhou]

Got v1.8 installed - runs smooth, no error messages!
I run the Enervu App v1.2.4, got the LG ESS Home 8 System with 9.8 kWh battery and all 3 strings attached. For home and common Home 8 and 3 strings should set the communication frame.

[gluap]

The meaning of this sentence is unclear to me:

For home and common Home 8 and 3 strings should set the communication frame.

My guess is you're summarizing what system the original issue occured for right? I'm asking because the "should" might also refer to what pyess should do but doesn't, indicating some persisting issue.

[fu-zhou]

You mentioned that The error you describe above does not happen on my ess, likely because the structure of /home/ and /common/ daata sources differs between our ESSes.
What I meant to say is that the contents of the common and home section "should" depend on the system one has and how many strings are connected. I.e. if your system and my system has the same configuration, there shouldn't be any difference in home and common. That's all, I didn't intend to summarize what system the original issue occured for. And also no intend to point out what pyess should do but doesn't. The "should" just came from my guess.

[gluap]

I fully agree, it should depend on the system :) Very good, sorry I didn't get it on the first try. Thank you for the clarification, closing this issue now.