rorr73 / lifesospy_mqtt Goto Github PK

Hi!
First thanks for this work! I just got it running on my WeBeHome version (LS-30). In my system I have the WeBeHome gateway (z-wave) connected but I wanted to get rid of that (paid service) as I am using HA for all my stuff now. I did not have the network module for my LS-30, but the gateway came with a $20 USB-to-Serial module that I simply plugged into a Pi3 instead og the provided gateway. Then, I set up a conversion from serial to tcp using ser2net. After this, I configured LifeSOSpy_MQTT to connect to this IP/port (localhost) and I just wanted to tell you that this works nicely. That means that LifeSOSpy_MQTT will work without the ethernet module as long as you can get your serial data into a Pi (or something else). I guess an alternative could be to set it up using socat also, but I selected ser2net this time.
Thanks gain!

Sorry to post this an issue, but I wanted to let you know in some way.
Stefan

First of, really good job. This lib works awesome for me. (Using it with LS-20).

I'm wondering if you have any plans to build a HassIO-addon with this lib?

I would love that myself, and I will try to do that, but want to see if there are any work in progress before I start.

I saw that someone has made a docker container with what I assume is this lib already. https://hub.docker.com/r/rpavlyuk/c7-lifesospy_mqtt. Is that you? If so, do you have any documentation on that or links where I can find the source code for the container?

It would be nice to have a binary sensor that shows the device battery status in Home Assistant.

We could make use of the BatteryLow and PowerOnReset event codes and present a low battery binary sensor that listen to the [device_id]/event_code topic.

The fact the the events are not retained doesnt matter as Home Assistant will keep track of the status for us in case of a connection lost/restart situation.

hi Richard, thanks for this great tool to give my lifesos a second life)
I just ran into a small issue:

pi@bereskapi-ha:/opt/mosquitto $ /home/pi/.local/bin/lifesospy_mqtt -e
lifesospy_mqtt v0.10.6 - MQTT client to report state of LifeSOS security system and devices.

Waiting for client connection...

it hangs on there for ever(

i think the problem is the BF-210 ethernet adapter I got from a third country which apparently has been used before.
I cannot access it via web interface with default user and password admin:admin
it shows up on my LAN no problem and gets an ip address from my router
and i can ping it too
but when I run nmap it gives me this:

MacBook-Air-DG:~ bereska$ nmap -p- 192.168.2.247
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-25 21:50 MSK
Nmap scan report for 192.168.2.247
Host is up (0.0049s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
80/tcp open http
99/tcp open metagram

so the listening port 1860 is closed

is there a way to reset this adapter? so I could access and configure it?

thanks for your help
Dmitry

Ho Robert,
hate to bother you again

now lifesospy_mqtt loses connection with HA at leat once day even though the daemon keeps on running ok and i see this error in mosquitto logs:

2019-01-31T01:17:05.913297666Z 1548897425: Client lifesos has exceeded timeout, disconnecting.,
2019-01-31T01:17:07.857499555Z 1548897425: Socket error on client lifesos, disconnecting.,
2019-01-31T01:17:23.107483161Z 1548897443: New connection from 172.18.0.1 on port 1883.,
2019-01-31T01:17:23.109819236Z 1548897443: Client lifesos disconnected.,
2019-01-31T01:17:23.110012829Z 1548897443: New client connected from 172.18.0.1 as lifesos (c0, k30, u'lifesos').,
2019-01-31T01:20:47.890736033Z 1548897647: Saving in-memory database to /mosquitto/data/mosquitto.db.

it looks like it connects back to ha but the alarm components remain unavailable until i manually restart lifesospyd.service

any ideas where to dig?
thank you
Dmitry

P.S. it started after upgrading to 0.86.1, not i am on 0.86.4

Hi Robert,
there is this one more thing I noticed long time ago which is rather an inconvenience than an issue ...
when the alarm gets triggered in disarmed mode by tampering with sensors (battery change, etc.), the HA alarm panel changes its state to TRIGGERED and does not allow to change it even though the DISARM button in present. Pressing the DISARM button has no effect. It stays this way until I manually reset it on the main unit and then run lifesosd.service restart
do you think it's possible to modify your code to allow for reset after triggered by tampering in HA alarm panel?

P.S. this morning I switched to from Samsung 32G SD card to a 2.5" SATA 128G SSD and it's been running just great on my rpi 3b+! Before the switch the boot time was about 6 min, now its only 2 min. Hope it will be more reliable and durable than SD, too.

After a PIR sensor is triggered, and an auto reset interval has been explicitly defined in the configuration file, the app will not automatically reset the motion sensor value. The following error is logged when it attempts to return to the 'no motion' state:

2019-10-18 08:00:42 ERROR (MainThread) [lifesospy.device] Unhandled exception in on_event callback
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/lifesospy/device.py", line 231, in _handle_device_event
    self._on_event(self, device_event.event_code)
  File "/usr/local/lib/python3.5/dist-packages/lifesospy_mqtt/translator.py", line 461, in _device_on_event
    self._auto_reset, device.device_id)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 541, in call_later
    timer = self.call_at(self.time() + delay, callback, *args)
TypeError: unsupported operand type(s) for +: 'float' and 'str'

Tracked the issue down to a change in previous release 0.11.4; by changing yaml.load to use the BaseLoader, it no longer deserializes the non-string values correctly. The 'auto_reset_interval' setting (defined as an 'int') is loaded only as a string, which results in the error when the app attempts to perform arithmetic on the string value.

Hi Richard, your script has been working like a rock, up until recently. I noticed my Home Alarm instance in Home assistant kept turning 'unavailable' and when I traced it back, the base unit was connecting okay (I pinged it 1k times and it didn't drop any packets), the mqtt broker was ok, but the script kept reporting disconnections.

2021-07-20 20:51:33 INFO (MainThread) [lifesospy.baseunit] Device discovery completed and got initial state
2021-07-20 20:53:22 ERROR (MainThread) [lifesospy.baseunit] Connection was lost. Will attempt to reconnect in 30 seconds
Traceback (most recent call last):
File "/usr/lib/python3.7/asyncio/selector_events.py", line 801, in _read_ready__data_received
data = self._sock.recv(self.max_size)
ConnectionResetError: [Errno 104] Connection reset by peer
2021-07-20 20:53:53 INFO (MainThread) [lifesospy.baseunit] Connected successfully

When starting the lifesospy_mqtt you get this warning.

/usr/lib/python3.7/site-packages/lifesospy_mqtt/config.py:208: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. settings = yaml.load(config_file) or {}

Hi,
i am running this on a Synology DS since years without any issue.
I think recently my Python got updated and I am getting the below error...

root@SNAS10TB:/volume1/@appstore/py3k/usr/local/bin# /volume1/@appstore/py3k/usr/local/bin/lifesospy_mqtt -w /volume1/SmartHome/LifeSOS/ -d -l -p
lifesospy_mqtt v0.11.5 - MQTT client to report state of LifeSOS security system and devices.

Starting daemon.
Traceback (most recent call last):
File "/volume1/@appstore/py3k/usr/local/bin/lifesospy_mqtt", line 8, in
sys.exit(main())
File "/var/packages/py3k/target/usr/local/lib/python3.8/site-packages/lifesospy_mqtt/main.py", line 124, in main
with daemon.DaemonContext(
File "/var/packages/py3k/target/usr/local/lib/python3.8/site-packages/daemon/daemon.py", line 280, in init
detach_process = is_detach_process_context_required()
File "/var/packages/py3k/target/usr/local/lib/python3.8/site-packages/daemon/daemon.py", line 801, in is_detach_process_context_required
if is_process_started_by_init() or is_process_started_by_superserver():
File "/var/packages/py3k/target/usr/local/lib/python3.8/site-packages/daemon/daemon.py", line 778, in is_process_started_by_superserver
if is_socket(stdin_fd):
File "/var/packages/py3k/target/usr/local/lib/python3.8/site-packages/daemon/daemon.py", line 743, in is_socket
file_socket = socket.fromfd(fd, socket.AF_INET, socket.SOCK_RAW)
File "/var/packages/py3k/target/usr/local/lib/python3.8/socket.py", line 544, in fromfd
return socket(family, type, proto, nfd)
File "/var/packages/py3k/target/usr/local/lib/python3.8/socket.py", line 231, in init
_socket.socket.init(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket

Any idea how to solve this?
Thanks

hi Robert,
I hate to bother you again
I struggle to have lifesospy_mqtt started after homeassistant restart and I need your help

as you know I have already enabled lifesospy_mqtt as a systemd service and works just fine after pi reboot, everything starts right up
however if I just restart homeassistant ('docker restart homeassistant'), lifesosd.service keeps on running but it never hooks up with homeassistant and I have to manually restart lifesosd.service ('sudo systemctl restart lifesosd.service')

I think the problem is that I run homeassistant in docker container and lifesospy_mqtt was installed on host
I have googled this problem around but could not find a solution
Please let me know your thoughts
regards,
Dmitry

I have noticed a strange behavior when the app is shutting down. It can take over 30 seconds for it to do so.

I have debugged as good as I can, and from what I can tell there is something in the translator::async_loop that causes this.

The shutdown signal is catched, and signal_shutdown executed, but then it might take some time until you receive a asyncio.CancelledError in the async_loop. Not sure why this might be that time consuming, but this is causing problem running this in a docker container as docker will send SIGKILL after 10 secounds if the container is not stopped or killed.

I would really appreciate if you could find some time and take a look at this.