Thanks, it’s perfect!
The fix for incoming SMS has been submitted a few hours ago. Hopefully it will be included in the next bug fix release.
1 Like
The version 2021.9.6 is just released but do not contain the fix. I don’t understand how things are in or out releases. This make no sense for me
By default new changes will go into the next month release (in this case October first). If we want to release sooner the change needs to be tagged for the service release (if any) in the current month, Setember.
@pvizeli @martinhjelmare Could we tag this fix for the next service release? This has been really painful.
1 Like
Yes, I have converted the device into serial mode using this tutorial.
I managed to solve the Failed to connect issue by updating HA Core to core-2021.9.6. After that, I’ve added device /dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0.
To answer my own previous question, whether SIM card connectivity is checked at this stage: No, I could add the integration without activated SIM card.
Then I activated the SIM card and verified that I can send SMS from mobile phone. I inserted the activated SIM card back to the modem.
I still cannot send SMS though.
I added
notify:
- platform: sms
name: sms_petr
recipient: +420731758732
to configuration.yaml and manually turned on the sensor.gsm_signal_imei_xxxxxxxx entity. But when I call notify.sms_service from http://homeassistant.local:8123/developer-tools/service, no SMS is received.
Is the recipient format right? Should there be country code? I tried both with and without, neither worked.
EDIT: It is working now. Probably hassio.host_reboot helped. I am using recipient without the country code.
1 Like
Reception of messages will not work until the fix is deployed. Hopefully next release in October
You mean will not work ?
Looks like the fix is in 2021.9.7:
Planning on upgrading from 2021.6.6 over the next couple of days.
1 Like
USB 800l v2, sms integration still not working.
HASS core version 2021.9.7
We need logs.
Maybe this is an specific incompatibility with this specific device.
Can the “SIM800L V2” be used with a Raspberry device? If so, I will get one and try to test it in my test environment.
Little bit more details:
Home Assistant 2021.9.7 core, running in VirtEnv on rpi4 4gb model. OS is on USB SSD.
SMS device - SIM80l v2. Device is recognized by the OS
Feb 18 20:12:02 rpi4 kernel: [ 5.888704] usb 1-1.2.2: ch341-uart converter now attached to ttyUSB0
(description QinHeng Electronics HL-340 USB-Serial adapter)
Device and sim tested directly on Linux and windows and it is working.
Rpi is powered by 5V UPS (5A-so no power issues) and all permission (groups) checked 3 times.
SMS by me stopped to work after the first September update.
Here is the HASS LOG entry when trying to initialize the sms integration.
Logger: homeassistant.components.sms.gateway
Source: components/sms/gateway.py:194
Integration: SMS notifications via GSM-modem (documentation, issues)
First occurred: 22:12:38 (1 occurrences)
Last logged: 22:12:38
Failed to initialize, error ERR_TIMEOUT
Time out meas either the device is not present or somehow is no longer supported by gammu.
In ssh, what is the output of:
ls -l /dev/*USB*
And:
lsusb
And:
ls -l /dev/*tty*
And
ls -l /etc/udev/rules.d/*.rules
And
ls -l /dev/serial
Like I write before. Device is detected by host OS and gammu is working, I use gammu-dev like the manual suggest .
ls /dev/ttyUS*
give
/dev/ttyUSB0
And by serial also detected
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 (the sim 800l v2)
/dev/serial/by-id/usb-Texas_Instruments_CC2538_USB_CDC-if00 (cc2538 zigbee)
Integration stopped working after the first september update
I assume you have try to remove the sms integration and try to add it again.
Another explanation is that something else is opening the serial port.
I will post some detailed diagnostic steps for testing gammu inside your container.
Yes, I did try to remove and add the integration several times.
I also did try to add the device using it as/dev/serial… but no success.
Device/port is free, I have confirmed it several times, also I did monitor the kernel and messages logs for any other service that may open or use the device.
Like I said before, integration stopped working suddenly after the first September update.
I’ve upgraded to 2021.9.7 and have both good and bad news.
- Good: sending and receiving works.
- Bad: receiving SMS causes a restart of homeassistant (the received message is processed on restart).
Docker instance on Ubuntu 18.4 using Huawei E220 unlocked USB modem.
@Oscar_Calvo sorry to be the bearer of bad news - I’ve updated the open GitHub issue Receiving SMS is causing crash of HomeAssistant · Issue #54876 · home-assistant/core · GitHub for restarts on receiving SMS with what logs I have for this, however it doesn’t seem to be anything useful to my untrained eye.
The received message is processed successfully after HA recovers from the crash.
I am confused, I thought your problem was a timeout during initialization?
Is that problem resolved?
Or are you using 2 different hassio systems?
Sorry for the late response. Here is the output:
ls -l /dev/*USB*
crw-rw---- 1 root dialout 188, 0 Sep 20 16:54 /dev/ttyUSB0
lsusb
Bus 002 Device 002: ID 8564:7000 Transcend Information, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 0451:16c8 Texas Instruments, Inc.
Bus 001 Device 004: ID 0513:0318 digital-X, Inc.
Bus 001 Device 008: ID 03f0:e207 HP, Inc
Bus 001 Device 007: ID 0458:707c KYE Systems Corp. (Mouse Systems)
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ls -l /dev/*tty*
crw-rw-rw- 1 root tty 5, 0 Sep 20 16:26 /dev/tty
crw–w---- 1 root tty 4, 0 Sep 20 16:26 /dev/tty0
crw–w---- 1 root tty 4, 1 Sep 20 16:26 /dev/tty1
crw–w---- 1 root tty 4, 10 Sep 20 16:26 /dev/tty10
crw–w---- 1 root tty 4, 11 Sep 20 16:26 /dev/tty11
crw–w---- 1 root tty 4, 12 Sep 20 16:26 /dev/tty12
crw–w---- 1 root tty 4, 13 Sep 20 16:26 /dev/tty13
crw–w---- 1 root tty 4, 14 Sep 20 16:26 /dev/tty14
crw–w---- 1 root tty 4, 15 Sep 20 16:26 /dev/tty15
crw–w---- 1 root tty 4, 16 Sep 20 16:26 /dev/tty16
crw–w---- 1 root tty 4, 17 Sep 20 16:26 /dev/tty17
crw–w---- 1 root tty 4, 18 Sep 20 16:26 /dev/tty18
crw–w---- 1 root tty 4, 19 Sep 20 16:26 /dev/tty19
crw–w---- 1 root tty 4, 2 Sep 20 16:26 /dev/tty2
crw–w---- 1 root tty 4, 20 Sep 20 16:26 /dev/tty20
crw–w---- 1 root tty 4, 21 Sep 20 16:26 /dev/tty21
crw–w---- 1 root tty 4, 22 Sep 20 16:26 /dev/tty22
crw–w---- 1 root tty 4, 23 Sep 20 16:26 /dev/tty23
crw–w---- 1 root tty 4, 24 Sep 20 16:26 /dev/tty24
crw–w---- 1 root tty 4, 25 Sep 20 16:26 /dev/tty25
crw–w---- 1 root tty 4, 26 Sep 20 16:26 /dev/tty26
crw–w---- 1 root tty 4, 27 Sep 20 16:26 /dev/tty27
crw–w---- 1 root tty 4, 28 Sep 20 16:26 /dev/tty28
crw–w---- 1 root tty 4, 29 Sep 20 16:26 /dev/tty29
crw–w---- 1 root tty 4, 3 Sep 20 16:26 /dev/tty3
crw–w---- 1 root tty 4, 30 Sep 20 16:26 /dev/tty30
crw–w---- 1 root tty 4, 31 Sep 20 16:26 /dev/tty31
crw–w---- 1 root tty 4, 32 Sep 20 16:26 /dev/tty32
crw–w---- 1 root tty 4, 33 Sep 20 16:26 /dev/tty33
crw–w---- 1 root tty 4, 34 Sep 20 16:26 /dev/tty34
crw–w---- 1 root tty 4, 35 Sep 20 16:26 /dev/tty35
crw–w---- 1 root tty 4, 36 Sep 20 16:26 /dev/tty36
crw–w---- 1 root tty 4, 37 Sep 20 16:26 /dev/tty37
crw–w---- 1 root tty 4, 38 Sep 20 16:26 /dev/tty38
crw–w---- 1 root tty 4, 39 Sep 20 16:26 /dev/tty39
crw–w---- 1 root tty 4, 4 Sep 20 16:26 /dev/tty4
crw–w---- 1 root tty 4, 40 Sep 20 16:26 /dev/tty40
crw–w---- 1 root tty 4, 41 Sep 20 16:26 /dev/tty41
crw–w---- 1 root tty 4, 42 Sep 20 16:26 /dev/tty42
crw–w---- 1 root tty 4, 43 Sep 20 16:26 /dev/tty43
crw–w---- 1 root tty 4, 44 Sep 20 16:26 /dev/tty44
crw–w---- 1 root tty 4, 45 Sep 20 16:26 /dev/tty45
crw–w---- 1 root tty 4, 46 Sep 20 16:26 /dev/tty46
crw–w---- 1 root tty 4, 47 Sep 20 16:26 /dev/tty47
crw–w---- 1 root tty 4, 48 Sep 20 16:26 /dev/tty48
crw–w---- 1 root tty 4, 49 Sep 20 16:26 /dev/tty49
crw–w---- 1 root tty 4, 5 Sep 20 16:26 /dev/tty5
crw–w---- 1 root tty 4, 50 Sep 20 16:26 /dev/tty50
crw–w---- 1 root tty 4, 51 Sep 20 16:26 /dev/tty51
crw–w---- 1 root tty 4, 52 Sep 20 16:26 /dev/tty52
crw–w---- 1 root tty 4, 53 Sep 20 16:26 /dev/tty53
crw–w---- 1 root tty 4, 54 Sep 20 16:26 /dev/tty54
crw–w---- 1 root tty 4, 55 Sep 20 16:26 /dev/tty55
crw–w---- 1 root tty 4, 56 Sep 20 16:26 /dev/tty56
crw–w---- 1 root tty 4, 57 Sep 20 16:26 /dev/tty57
crw–w---- 1 root tty 4, 58 Sep 20 16:26 /dev/tty58
crw–w---- 1 root tty 4, 59 Sep 20 16:26 /dev/tty59
crw–w---- 1 root tty 4, 6 Sep 20 16:26 /dev/tty6
crw–w---- 1 root tty 4, 60 Sep 20 16:26 /dev/tty60
crw–w---- 1 root tty 4, 61 Sep 20 16:26 /dev/tty61
crw–w---- 1 root tty 4, 62 Sep 20 16:26 /dev/tty62
crw–w---- 1 root tty 4, 63 Sep 20 16:26 /dev/tty63
crw–w---- 1 root tty 4, 7 Sep 20 16:26 /dev/tty7
crw–w---- 1 root tty 4, 8 Sep 20 16:26 /dev/tty8
crw–w---- 1 root tty 4, 9 Sep 20 16:26 /dev/tty9
crw-rw---- 1 root dialout 166, 0 Sep 20 16:26 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64 Sep 20 16:26 /dev/ttyAMA0
crw------- 1 root root 5, 3 Sep 20 16:26 /dev/ttyprintk
crw-rw---- 1 root dialout 4, 64 Feb 14 2019 /dev/ttyS0
crw-rw---- 1 root dialout 188, 0 Sep 20 16:54 /dev/ttyUSB0
ls -l /etc/udev/rules.d/*.rules
-rw-r–r-- 1 root root 58549 Jan 29 2021 /etc/udev/rules.d/70-snap.core.rules
-rw-r–r-- 1 root root 1917 Oct 26 2020 /etc/udev/rules.d/99-com.rules
ls -l /dev/serial
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
P.S. GSM Modem is SIM 800C v2 (not a DIY solution).
Homessistant user is in the dial-up and gpio and i2c groups included.
Like I write before - it used to work flawlessly until the first September Update.
Unfortunately, receiving messages with SIM800 still restarts Supervisor for me, with no entry in either logs.
Running HAOS on Intel NUC with latest versions for both Core and Supervisor.