Closed niraviry closed 1 year ago
Hi. Thanks for your report. The error messages needs a bit of work to be more user friendly, as seen in #41 😅 Error code 1 if I remember correctly means that username or password is incorrect. Please double check you configuration and report back.
That was fast. I do not think it is but I will double check.
Sorry. A small typo. Fixed.
All sensors seems to exist. Checking things. Will let you know.
binary_sensors look OK. The only thing I do not manage to work is the hassio.addon_stdin. I am not sure I use the correct io name. The host shows in the info page a53439b8-hikvision-doorbell-beta. No response in the log for it nor for the a53439b8_hikvision_doorbell. Where can I find the correct stdin name?
Hi, have a look in the url itself in your browser :+)
You can try the "developer tools" -> "services" UI to invoke the hassio stdin service. It should display in the popup window the addons available with their id.
On Sat, Feb 25, 2023, 13:18 Pergola Fabio @.***> wrote:
Hi, have a look in the url itself in your browser :+)
— Reply to this email directly, view it on GitHub https://github.com/pergolafabio/Hikvision-Addons/issues/73#issuecomment-1445084084, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCNHN7YX4UBBRKLEGUJ5WDWZH2BPANCNFSM6AAAAAAVHYQGCE . You are receiving this because you commented.Message ID: @.***>
Got that. Thanks.
Now the Unlock command works but the reject shoots an error as follows:
2023-02-25 17:08:13.303 | DEBUG | input:loop_forever:36 - Received: reject front_gate 2023-02-25 17:08:13.307 | INFO | input:execute_command:77 - Rejecting the call 2023-02-25 17:08:13.309 | DEBUG | doorbell:call_signal:110 - Request body: {"CallSignal": {"cmdType": "reject"}} [2023-02-25 17:08:13.320][INF] Private connect 10.0.0.11:8000 sock=8 this=0x96f67e00 cmd=0x117001 port=42146 2023-02-25 17:08:13.339 | DEBUG | doorbell:call_signal:149 - Response buffer: { "requestURL": "/ISAPI/VideoIntercom/callSignal", "statusCode": 6, "statusString": "Invalid Content", "subStatusCode": "badXmlContent", "errorCode": 1610612739, "errorMsg": "Wrong XMLcontent" } 2023-02-25 17:08:13.340 | DEBUG | doorbell:call_signal:150 - Response output: size: 200, value: 2023-02-25 17:08:13.342 | ERROR | doorbell:call_signal:152 - Result error: 11 [2023-02-25 17:08:13.339][DBG] SimpleSTDCommandToDvr with out cmd[PUT /ISAPI/VideoIntercom/callSignal?format=json], input size[37], max segment length[262144]
I have used the following input options:
reject
reject front_gate
reject front_gate 1
All cause the same error.
What device do you have? Have you also indoor? Try sending to indoor...
BTW, I own the 8003 with version 2.2.52. (Hebrew support) and 6320-TE1 indoor station. Hebrew versions are slow due to Hikvision Europe slow response.
What do you mean by "sending to indoor"? Is it instead of front_gate? If so I did not set any name to it as it is not part of the setup.
Reject from my understanding works only if sent during an incoming call to the indoor unit, if you have one.
On Sat, Feb 25, 2023, 16:11 niraviry @.***> wrote:
Got that. Thanks. Now the Unlock command works but the reject shoots an error as follows: 2023-02-25 17:08:13.303 | DEBUG | input:loop_forever:36 - Received: reject front_gate 2023-02-25 17:08:13.307 | INFO | input:execute_command:77 - Rejecting the call 2023-02-25 17:08:13.309 | DEBUG | doorbell:call_signal:110 - Request body: {"CallSignal": {"cmdType": "reject"}} [2023-02-25 17:08:13.320][INF] Private connect 10.0.0.11:8000 sock=8 this=0x96f67e00 cmd=0x117001 port=42146 2023-02-25 17:08:13.339 | DEBUG | doorbell:call_signal:149 - Response buffer: { "requestURL": "/ISAPI/VideoIntercom/callSignal", "statusCode": 6, "statusString": "Invalid Content", "subStatusCode": "badXmlContent", "errorCode": 1610612739, "errorMsg": "Wrong XMLcontent" } 2023-02-25 17:08:13.340 | DEBUG | doorbell:call_signal:150 - Response output: size: 200, value: 2023-02-25 17:08:13.342 | ERROR | doorbell:call_signal:152 - Result error: 11 [2023-02-25 17:08:13.339][DBG] SimpleSTDCommandToDvr with out cmd[PUT /ISAPI/VideoIntercom/callSignal?format=json], input size[37], max segment length[262144] I have used the following input options: reject reject front_gate reject front_gate 1
All cause the same error.
— Reply to this email directly, view it on GitHub https://github.com/pergolafabio/Hikvision-Addons/issues/73#issuecomment-1445139285, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCNHN4N43XUICGFCS5DNMLWZIOIXANCNFSM6AAAAAAVHYQGCE . You are receiving this because you commented.Message ID: @.***>
It works the same, with or without a call.
What do you mean by "sending to indoor"? Is it instead of front_gate? If so I did not set any name to it as it is not part of the setup.
Try adding also the indoor unit to you add-on configuration, then send the reject
command to using its name
OK. Will try.
I have edited the configuration under YAML, added another device named main_indoor_panel, restarted the add-on, restarted the HA. There are no binary_sensor.main* at all.
After reboot, the front_door is gone as well although it appears without an error in the ad-on log. Once the indoor entity was removed the front_gate returned to function.
Do you see any log in the add-on like Setting up event handler: Home Assistant API
After rebooting the Add-on, I can see:
2023-02-25 22:07:54.370 | DEBUG | event:register_handler:183 - Adding event handler HomeAssistantAPI
This is when only the front_gate is defined.
If you wish, I can do it for both front_gate and main_indoor_panel
Try to define both devices in the add-on configuration. What kind of problem do you have when both are used?
Can you also show us a screenshot how you configured the addon?
I have just upgraded the 8003 to version 2.2.56. Now it seems like the 1st device (the outdoor panel) is getting all its entities (binary_sensor etc.) The 2nd one does not. The configuration is:
> - name: front_gate
ip: 10.0.0.11
username: admin
password: xxxxxxxx
- name: main_indoor_panel
ip: 10.0.0.12
username: admin
password: xxxxxxxxx
The output after reboot is:
2023-02-26 18:55:01.120 | DEBUG | __main__:main:24 - Importing Hikvision SDK
2023-02-26 18:55:01.134 | INFO | sdk.utils:loadSDK:44 - Using OS: Linux with architecture: aarch64
2023-02-26 18:55:01.135 | DEBUG | sdk.utils:loadSDK:57 - Loading library from lib-aarch64/libhcnetsdk.so
hpr tls index{3}
2023-02-26 18:55:01.177 | DEBUG | __main__:main:28 - Hikvision SDK loaded
2023-02-26 18:55:01.178 | DEBUG | sdk.utils:setupSDK:83 - Initializing SDK
loop[2] find 2 mac and 0 ip
[2023-02-26 18:55:01.206][DBG] CCoreGlobalCtrlBase::LoadDSo, HPR_LoadDSo Succ, Path[/lib/aarch64-linux-gnu/libz.so.1.2.11], hHandleRet[-1129547184]
[2023-02-26 18:55:01.206][INF] The COM:HCCoreBase ver is 6.1.4.15, 2020_03_05. Async:1.
[2023-02-26 18:55:01.207][INF] The COM:Core ver is 6.1.8.101, 2021_12_10. Async:1.
[2023-02-26 18:55:01.207][INF] This HCNetSDK ver is 6.1.8.101 Ver 2021_12_10.
2023-02-26 18:55:01.207 | DEBUG | sdk.utils:setupSDK:97 - SDK initialized
2023-02-26 18:55:01.208 | DEBUG | doorbell:__init__:38 - Setting up doorbell: front_gate
2023-02-26 18:55:01.209 | DEBUG | doorbell:authenticate:45 - Logging into doorbell
[2023-02-26 18:55:01.210][INF] Login dev 10.0.0.11:8000.
[2023-02-26 18:55:01.210][INF] dwTotalNum[2048]
[2023-02-26 18:55:01.212][INF] Private connect 10.0.0.11:8000 sock=7 this=0xbce3d8e4 cmd=0x10000 port=55984
[2023-02-26 18:55:01.212][INF] LogonDev1 in[10.0.0.11:8000]
[2023-02-26 18:55:01.214][DBG] CCoreGlobalCtrlBase::LoadDSo, HPR_LoadDSo Succ, Path[/app/lib-aarch64/libcrypto.so], hHandleRet[-1126455504]
[2023-02-26 18:55:01.216][DBG] CCoreGlobalCtrlBase::LoadDSo, HPR_LoadDSo Succ, Path[/app/lib-aarch64/libssl.so], hHandleRet[-1126454240]
[2023-02-26 18:55:01.216][INF] SSLTRANSAPI::LoadAPI, libeay, Load Real Path[/app/lib-aarch64/libcrypto.so]
[2023-02-26 18:55:01.216][INF] SSLTRANSAPI::IsAllAPILoaded, SSL_library_init Unload
[2023-02-26 18:55:01.216][INF] OpenSSL, Not All Function Loaded!
[2023-02-26 18:55:01.216][INF] SSLTRANSAPI::PrintVersion, OpenSSL version info [OpenSSL 1.1.1i 8 Dec 2020]
[2023-02-26 18:55:01.216][INF] CSSLTrans::SSLCtxInit, dwSSLVersion[6], m_fnTLSServerMethod
2023-02-26 18:55:02.324 | DEBUG | doorbell:authenticate:63 - Login returned user ID: 0
2023-02-26 18:55:02.325 | DEBUG | doorbell:authenticate:64 - Doorbell serial number: 6883457568564848514573776949476985484950485048485548578282695356495554505154, device type: OUTDOOR
2023-02-26 18:55:02.326 | INFO | doorbell:authenticate:66 - Connected to doorbell: front_gate
2023-02-26 18:55:02.327 | DEBUG | doorbell:__init__:38 - Setting up doorbell: main_indoor_panel
2023-02-26 18:55:02.329 | DEBUG | doorbell:authenticate:45 - Logging into doorbell
[2023-02-26 18:55:02.330][INF] Login dev 10.0.0.12:8000.
[2023-02-26 18:55:02.331][INF] Private connect 10.0.0.12:8000 sock=7 this=0xbce3d8e4 cmd=0x10000 port=59780
[2023-02-26 18:55:02.332][INF] LogonDev1 in[10.0.0.12:8000]
2023-02-26 18:55:02.351 | DEBUG | doorbell:authenticate:63 - Login returned user ID: 1
2023-02-26 18:55:02.352 | DEBUG | doorbell:authenticate:64 - Doorbell serial number: 68834575725451504845846949484950485048485748508782814851494948484851677685, device type: INDOOR
2023-02-26 18:55:02.352 | INFO | doorbell:authenticate:66 - Connected to doorbell: main_indoor_panel
2023-02-26 18:55:02.353 | INFO | event:__init__:66 - Setting up event handler: Console stdout
2023-02-26 18:55:02.354 | DEBUG | event:register_handler:183 - Adding event handler ConsoleSTDOUT
2023-02-26 18:55:02.355 | INFO | home_assistant:__init__:41 - Setting up event handler: Home Assistant API
2023-02-26 18:55:02.403 | DEBUG | home_assistant:update_sensor:97 - Response {"entity_id":"binary_sensor.front_gate_door","state":"off","attributes":{"device_class":"door","friendly_name":"front_gate door"},"last_changed":"2023-02-26T16:28:12.393788+00:00","last_updated":"2023-02-26T16:28:12.393788+00:00","context":{"id":"01GT78V8Q9CKV160GT15QHEVAX","parent_id":null,"user_id":"7e3b4977501643ba8c500fe90d9643ba"}} {'entity_id': 'binary_sensor.front_gate_door', 'state': 'off', 'attributes': {'device_class': 'door', 'friendly_name': 'front_gate door'}, 'last_changed': '2023-02-26T16:28:12.393788+00:00', 'last_updated': '2023-02-26T16:28:12.393788+00:00', 'context': {'id': '01GT78V8Q9CKV160GT15QHEVAX', 'parent_id': None, 'user_id': '7e3b4977501643ba8c500fe90d9643ba'}}
2023-02-26 18:55:02.438 | DEBUG | home_assistant:update_sensor:97 - Response {"entity_id":"binary_sensor.front_gate_callstatus","state":"off","attributes":{"device_class":"sound","friendly_name":"front_gate callstatus"},"last_changed":"2023-02-25T16:06:40.435312+00:00","last_updated":"2023-02-25T16:06:40.435312+00:00","context":{"id":"01GT4N741K17Z3PBRMC9B7EB5M","parent_id":null,"user_id":"7e3b4977501643ba8c500fe90d9643ba"}} {'entity_id': 'binary_sensor.front_gate_callstatus', 'state': 'off', 'attributes': {'device_class': 'sound', 'friendly_name': 'front_gate callstatus'}, 'last_changed': '2023-02-25T16:06:40.435312+00:00', 'last_updated': '2023-02-25T16:06:40.435312+00:00', 'context': {'id': '01GT4N741K17Z3PBRMC9B7EB5M', 'parent_id': None, 'user_id': '7e3b4977501643ba8c500fe90d9643ba'}}
2023-02-26 18:55:02.473 | DEBUG | home_assistant:update_sensor:97 - Response {"entity_id":"binary_sensor.front_gate_motion","state":"off","attributes":{"device_class":"motion","friendly_name":"front_gate motion"},"last_changed":"2023-02-25T16:06:40.472653+00:00","last_updated":"2023-02-25T16:06:40.472653+00:00","context":{"id":"01GT4N742RR3976W36BE8H2BSY","parent_id":null,"user_id":"7e3b4977501643ba8c500fe90d9643ba"}} {'entity_id': 'binary_sensor.front_gate_motion', 'state': 'off', 'attributes': {'device_class': 'motion', 'friendly_name': 'front_gate motion'}, 'last_changed': '2023-02-25T16:06:40.472653+00:00', 'last_updated': '2023-02-25T16:06:40.472653+00:00', 'context': {'id': '01GT4N742RR3976W36BE8H2BSY', 'parent_id': None, 'user_id': '7e3b4977501643ba8c500fe90d9643ba'}}
2023-02-26 18:55:02.512 | DEBUG | home_assistant:update_sensor:97 - Response {"entity_id":"binary_sensor.front_gate_tamper","state":"off","attributes":{"device_class":"tamper","friendly_name":"front_gate tamper"},"last_changed":"2023-02-26T16:36:38.948068+00:00","last_updated":"2023-02-26T16:36:38.948068+00:00","context":{"id":"01GT79AQD3HEQCRWA3FGX713YX","parent_id":null,"user_id":"7e3b4977501643ba8c500fe90d9643ba"}} {'entity_id': 'binary_sensor.front_gate_tamper', 'state': 'off', 'attributes': {'device_class': 'tamper', 'friendly_name': 'front_gate tamper'}, 'last_changed': '2023-02-26T16:36:38.948068+00:00', 'last_updated': '2023-02-26T16:36:38.948068+00:00', 'context': {'id': '01GT79AQD3HEQCRWA3FGX713YX', 'parent_id': None, 'user_id': '7e3b4977501643ba8c500fe90d9643ba'}}
2023-02-26 18:55:02.545 | DEBUG | home_assistant:update_sensor:97 - Response {"entity_id":"binary_sensor.front_gate_dismiss","state":"off","attributes":{"friendly_name":"front_gate dismiss"},"last_changed":"2023-02-25T16:06:40.556802+00:00","last_updated":"2023-02-25T16:06:40.556802+00:00","context":{"id":"01GT4N745CKV8P62V9S17SZMRX","parent_id":null,"user_id":"7e3b4977501643ba8c500fe90d9643ba"}} {'entity_id': 'binary_sensor.front_gate_dismiss', 'state': 'off', 'attributes': {'friendly_name': 'front_gate dismiss'}, 'last_changed': '2023-02-25T16:06:40.556802+00:00', 'last_updated': '2023-02-25T16:06:40.556802+00:00', 'context': {'id': '01GT4N745CKV8P62V9S17SZMRX', 'parent_id': None, 'user_id': '7e3b4977501643ba8c500fe90d9643ba'}}
2023-02-26 18:55:02.546 | DEBUG | event:register_handler:183 - Adding event handler HomeAssistantAPI
2023-02-26 18:55:02.547 | DEBUG | event:start:204 - Registering callback function using SDK
2023-02-26 18:55:02.548 | DEBUG | doorbell:setup_alarm:76 - Arming the device via SDK
[2023-02-26 18:55:02.553][DBG] CComBase::Load, Load szDllPath[/app/lib-aarch64/HCNetSDKCom/libHCAlarm.so] SUCC
[2023-02-26 18:55:02.553][INF] AbilityAnalyze---Init-- start
[2023-02-26 18:55:02.555][DBG] AbilityAnalyze---Init-- over, DeviceList path [/app/lib-aarch64/HCNetSDKCom/LocalXml/DeviceList.xml], load result[0]
[2023-02-26 18:55:02.556][INF] The COM:HCAlarm ver is 6.1.8.101, 2021_12_10.
[2023-02-26 18:55:02.559][INF] Private connect 10.0.0.11:8000 sock=7 this=0xbce3d8e4 cmd=0x111020 port=55862
2023-02-26 18:55:02.573 | DEBUG | doorbell:setup_alarm:76 - Arming the device via SDK
2023-02-26 18:55:02.579 | DEBUG | input:loop_forever:26 - Waiting for input command
[2023-02-26 18:55:02.575][INF] Private connect 10.0.0.12:8000 sock=8 this=0xbce3de00 cmd=0x111020 port=59792
Waiting for your answer. BTW, I will be on vacation starting tomorrow for a week so answers might not be handy. It looks like the add-on can't handle 2 devices together.
The indoor device does not have sensors created inside HA, since (at the moment, with my limited testing) i could get the indoor unit to generate any event. If you see any event coming from the indoor unit please let me know so I can act accordingly
Good morning. I have tried to use the panel instead of the outdoor. It does not create any entity at all. I am back with the outdoor panel. Reject does not help. I use 2.2.56. When I have upgraded, I did not do any factory reset but at this point, all seems to work OK except this one. I will away for a week so no news at this period.
Yes, as I said the indoor unit does not create any entity inside HA, but it can still receive commands from the add-on, it is not visible in the UI, but it is still there. I know this is a bit confusing, and maybe with the future MQTT integration things will be a bit more clear.
Have you tried to call the hass.stdin
service with reject main_indoor_panel
?
Reject from my understanding works only if sent during an incoming call to the indoor unit, if you have one.
Just to clear up, there are Hikvision models as standalone outdoor stations, without indoor, then the reject command needs to be send to outdoor... Devices with indoor, like 8003 , then rejects to be send to indoor
Hi.
Just got back from my vacation. I have tried adding the indoor panel and adding the reject call from it. Although it does not appear even in beta 9, it works. Many thanks. Now I am left with the audio. As I understand, two way audio is now possible ith the new webRTC.
Hi.
Just got back from my vacation. I have tried adding the indoor panel and adding the reject call from it. Although it does not appear even in beta 9, it works. Many thanks. Now I am left with the audio. As I understand, two way audio is now possible ith the new webRTC.
Sorry what do you mean it does not appear?
Another issue. It seems like the callstatus binary_sensor is indicating a ringing not like Hik-Connect integration and not like it should be, meaning it is supposed to be on through the whole time there is a ring. The binary_sensor just detects the button press and return once press was stopped it returned to off state. It should stay on through the hole time until the timeout or a call reject was run.
Another issue. It seems like the callstatus binary_sensor is indicating a ringing not like Hik-Connect integration and not like it should be, meaning it is supposed to be on through the whole time there is a ring. The binary_sensor just detects the button press and return once press was stopped it returned to off state. It should stay on through the hole time until the timeout or a call reject was run.
Yeas, thanks for pointing this out. We are aware of this limitation, due to the way binary_sensor
works. The upcoming MQTT integration should correctly display the call state (idle, ringing, dismissed).
thnx for all feedback, appreciated
Twoway audio is indeed possible, will be probably released in a few weeks as oficiial, with extra documentation in the go2rtc addon , keep an eye on it
Good. Any work on BiDi audio due to the newwebRTC?
audio comes with rtsp backchannel, so should be present
Can you elaborate on RTSP Backchannel?
If you create the stream in go2rtc , you define for video the rtsp stream, that one also gives audio, so you can hear audio... The ISAPi url, is only to send audio, it's not implemented to retrieve, not needed , since audio is already present in rtsp stream
Starting to play and understand how to use the go2rtc.
If I understand you correctly, in the go2rtc.yaml you define the following for the Hikvision 8003 (in my case):
streams: gate_rtsp: rtsp://user:PW@10.0.0.xx:554/ch1/main/av_stream
When doing so, I can see the intercom stream using the go2rtc GUI in my PC's browser with a speaker icon that is muted on start up but anfter unmuting,I here no sound. What am I missing?
have a look at this post: https://community.home-assistant.io/t/add-on-hikvision-doorbell-integration/532796/92
also, its normal that sensors are gone when HA ie restarted, they come back after restart Addon OR on first event Thats why we decided because of this limitation, we dropped HTTP api calls
From next beta version, MQTT will be mandatory! No more lost sensors ... much better handling
Hi. Tested the links. The RTSP stream does not work. Only the 1st one (from you original Hikvision Intercom post) work e.i. rtsp://user:pass@192.168.0.xx:554/ch1/main/av_stream. As I have said, it loads with speaker in off state. Anyway, I will wait for MQTT version and go on from there but I believe it has nothing to do with the stream name. I have another option and that is the BlueIris (BI) stream which works nice but I am not sure it supports audio. Under BI there is audio (I think 2 way). My home NVR is BI and it is a great thing.
Blueiris doesnt work, they only use onvif or rtsp backchannel, thats not supported on Hikvision
I only know Synology SS works, they customized it with ISAPI
Strange that isapi doesnt work for you
whats the output when you do these 2 commands?
curl -i --digest -u admin:xxx -X PUT http://192.168.0.x/ISAPI/System/TwoWayAudio/channels/1/open
curl -i --digest -u admin:xxx http://192.168.0.x/ISAPI/System/TwoWayAudio/channels/1/audioData
I have it configured like below, works for me, rtsp is offcourse different for you, but ISAPI should be the same
streams:
hikvision:
- rtsp://admin:XXX@192.168.0.70:554/Streaming/Channels/102
- isapi://admin:XXX@192.168.0.70/
For one,I use the Hebrew derivative of 2.2.56. I assume it is different only in voice messages etc. but it is just a guess and common sense. Actually when used these commands way back when the whole business of Hikvision intercom HA integration started, these streams never worked even in older versions. as for the commands, for the 1st one I get:
`HTTP/1.1 401 Unauthorized Date: Fri, 10 Mar 2023 13:06:43 GMT Server: webs Content-Length: 235 Connection: close X-Frame-Options: SAMEORIGIN Cache-Control: no-store Pragma: no-cache WWW-Authenticate: Digest qop="auth", realm="DS-E6B83D44", nonce="MWRmZDgyMTE1ODMzYzA3Mzg3MTM5MTEwY2U5MWEyYjA=", stale="false", opaque="", domain="::" Content-Type: application/xml
HTTP/1.1 200 OK Date: Fri, 10 Mar 2023 13:06:43 GMT Server: webs Content-Length: 201 Connection: close X-Frame-Options: SAMEORIGIN Cache-Control: no-store Pragma: no-cache Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
Ok, yeah, those commands works indeed, strange
For me it works perfectly with go2rtc, but I access the webui with a valid SSL , so with https, that's a requirement to make the microphone active in chrome
So at this point what you are saying is that the RTSP stream being used in go2rtc is the 1st key to understand why it does not work. I have to figure out a way to understand why it does not work. Than probably comes the issue with the mic (SSL). BTW both Streaming/Channels/101 and Streaming/Channels/102 do not work.
Yeah the rtsp urls can change indeed , but that doesn't mather, the ISAPi:// is the one important...
But what doesn't work?? How do you test it?
Back again. when I use the streams: gate_rtsp: rtsp://user:PW@10.0.0.xx:554/ch1/main/av_stream
stream, under go2rcp, I can hear the incoming sound from my intercom.
As I have said it is not the same one you use but the speaker works.
I have to verify how to use it with a mic. Not sure yet.
As for MQTT, it looks like it is working. I got the sensors, buttons etc. I can say that when I have added the location, I had to re-boot in order to re-activate the sensors. They all went to not ready once a location was defined.
I can also add that the gate status (open or close) is missing. It existed before on beta 9 version.
Hi, all existing binary sensors are gone , since the MQTT introduction, you should see new entiies... can you have a look here?
Integrations => mqtt => device => ...
ex:
I know that but looking at my setup and your port are both the same. Now there is no sensor that shows the state of the gate/door. Is it physically opened or closed. I have a magnetic sensor that is hooked to the outdoor station. It was working before the MQTT.
I know that but looking at my setup and your port are both the same. Now there is no sensor that shows the state of the gate/door. Is it physically opened or closed. I have a magnetic sensor that is hooked to the outdoor station. It was working before the MQTT.
Are you referring to the door 1 relay
switch? I think I might have a clue about what's wrong. Can you please restart the add-on with debug logs and attach here the logs please?
Hmm, normally nothing changed there, before there was a binary_sensor.door , that triggerd for 2 sec to on, when door was openened ... Now there is a switch.door , that also triggers to open when door was opened
?
Just installed the Beta 5 verion. Rest is latest verion. As mentioned I have removed the SDK add-on. I have left the home-assistant URL as is as there is no documentation for it. I an getting an error that looks like a fata one and add-on will not start:
What seems to be the problem?