Closed andriej closed 5 years ago
The spikes you are showing are no more than 30% for a short time. That’s not weird on a Pi running home assistant as well. Can you ensure the service takes up 100% cpu for an extended amount of time?
This machine runs nothing more than services near HA. Right now 'top' shows python 100% and connection with nodemcu is lost until restart (of service), couldn't turn off boiler
For test purpose I've switched back to this fork (was using it before). Will compare directly.
I've had just the same issues with hanging process and reconnection problems - issue is there. I've switched to HA native OTGW and also platform from WiFi to LAN connection to OTGW.
Comparison of same machine without any changes in system:
Hi andriej,
I've just added a message explaining the fact that I'm not actively maintaining this package anymore. This means I'll not be fixing bugs. Of course, if you're able to fix the issue I'm open to accept a pull request.
@martenjacobs maybe add link to https://github.com/mvn23/pyotgw which is actively supported and has already fixed all the issues that showed up also with py-otgw-mqtt
I've added some suggestions to the README file. However, the repo you're referring to is not a replacement for this one. For as far as I can tell, it's only a library that enables communications with an OTGW (either through a serial port or TCP). There's no daemon built to send that data somewhere. So basically: it's possible to re-implement this application using the library by @mvn23, but it's not a replacement in itself. The Home Assistant component can be a full replacement in some use cases, so in chose to mention that (I think that's probably based on the pyotgw library, by the way).
I'm running tcpbranch and I've had to setup a cron job to restart service every time it starts to eat 100% cpu. It runs for some random time properly and without any special reason process start to consume more and more CPU soon to make whole machine eath 10% of CPU. Data is reported in meanwhile, but sometimes not - can't find why yet.
All spikes are from python process of py-otgw-mqtt service.![image](https://user-images.githubusercontent.com/6303489/54057709-fa143f00-41f3-11e9-8938-654f90155c88.png)