Did you make any progress, Daniel?
Hi,
I got sniffer but didnāt try it yet, because I didnāt have a time.
I think I need to upload esp firmware on it, connect it to alarm panel, configure alarm for another keyboard and then see will I receive any messages.
But maybe I will postpone this after summer break.
Hi, @francescoca
I connected rs485 module to esp board and connected everything to rs485 alarm port.
For connection between module and esp32 board I used this article.
I connected esp32 board to positive and ground connections on rs485 alarm bus and A and B connections from module to the same connections on alarm bus.
I tried to wrote some firmware for using online resources and currently it looks like this
name: esphome-web-f541d4
friendly_name: amc alarm
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
level: VERY_VERBOSE
baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: "xxxxxxxx"
ota:
wifi:
ssid: "xxx"
password: "xxx"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "xxx"
password: "xxxx"
captive_portal:
uart:
id: mod_bus
tx_pin: GPIO1
rx_pin: GPIO3
baud_rate: 115200
stop_bits: 1
debug:
direction: BOTH
dummy_receiver: false
after:
timeout: 1s
sequence:
- lambda: UARTDebug::log_hex(direction, bytes,' ');
modbus:
flow_control_pin: 5
id: modbus1
modbus_controller:
- id: amc
## the Modbus device addr
address: 0x1
modbus_id: modbus1
setup_priority: -10
This is what I got from esp log
[11:56:59][V][mdns:114]: Services:
[11:56:59][V][mdns:116]: - _esphomelib, _tcp, 6053
[11:56:59][V][mdns:118]: TXT: friendly_name = amc alarm
[11:56:59][V][mdns:118]: TXT: version = 2023.8.3
[11:56:59][V][mdns:118]: TXT: mac = c8f09ef541d4
[11:56:59][V][mdns:118]: TXT: platform = ESP32
[11:56:59][V][mdns:118]: TXT: board = esp32dev
[11:56:59][V][mdns:118]: TXT: network = wifi
[11:56:59][V][mdns:118]: TXT: api_encryption = Noise_NNpsk0_25519_ChaChaPoly_SHA256
[11:56:59][C][ota:093]: Over-The-Air Updates:
[11:56:59][C][ota:094]: Address: esphome-web-f541d4.local:3232
[11:56:59][C][api:138]: API Server:
[11:56:59][C][api:139]: Address: esphome-web-f541d4.local:6053
[11:56:59][C][api:141]: Using noise encryption: YES
[11:56:59][C][modbus_controller:275]: ModbusController:
[11:56:59][C][modbus_controller:276]: Address: 0x01
[11:56:59][C][modbus_controller:278]: sensormap
[11:56:59][C][modbus_controller:284]: ranges
[11:57:17][VV][scheduler:226]: Running interval '' with interval=60000 last_execution=4294937751 (now=30456)
[11:57:18][VV][api.service:540]: on_ping_request: PingRequest {}
[11:57:18][VV][api.service:043]: send_ping_response: PingResponse {}
[11:57:34][VV][api.service:540]: on_ping_request: PingRequest {}
[11:57:34][VV][api.service:043]: send_ping_response: PingResponse {}
[11:57:38][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=4294958288 (now=50993)
[11:57:38][V][modbus_controller:158]: Updating modbus component
[11:57:38][VV][api.service:540]: on_ping_request: PingRequest {}
[11:57:38][VV][api.service:043]: send_ping_response: PingResponse {}
[11:57:58][VV][api.service:540]: on_ping_request: PingRequest {}
[11:57:58][VV][api.service:043]: send_ping_response: PingResponse {}
[11:58:14][VV][api.service:540]: on_ping_request: PingRequest {}
[11:58:14][VV][api.service:043]: send_ping_response: PingResponse {}
[11:58:17][VV][scheduler:226]: Running interval '' with interval=60000 last_execution=30455 (now=90456)
[11:58:18][VV][api.service:540]: on_ping_request: PingRequest {}
[11:58:18][VV][api.service:043]: send_ping_response: PingResponse {}
[11:58:38][VV][scheduler:226]: Running interval 'update' with interval=60000 last_execution=50992 (now=110995)
[11:58:38][V][modbus_controller:158]: Updating modbus component
[11:58:38][VV][api.service:540]: on_ping_request: PingRequest {}
[11:58:38][VV][api.service:043]: send_ping_response: PingResponse {}
[11:58:55][VV][api.service:540]: on_ping_request: PingRequest {}
[11:58:55][VV][api.service:043]: send_ping_response: PingResponse {}
[11:58:58][VV][api.service:540]: on_ping_request: PingRequest {}
[11:58:58][VV][api.service:043]: send_ping_response: PingResponse {}
[11:59:17][VV][scheduler:226]: Running interval '' with interval=60000 last_execution=90455 (now=150456)
[11:59:18][VV][api.service:540]: on_ping_request: PingRequest {}
[11:59:18][VV][api.service:043]: send_ping_response: PingResponse {}
Can you help ?
It seems that I made some progress. After tinkering with it all day it crossed my mind that maybe I should change modbus address from 1 to 2. I already have uniqa connected to the rs485 bus so it will be logical that it uses address 1. After changing code to this
modbus_controller:
- id: amc
## the Modbus device addr
address: 2
modbus_id: modbus1
setup_priority: -10
I started to get some info like this
[16:48:08][V][modbus:199]: Modbus write: 02.04.00.05.00.01.21.F8 (8)
[16:48:08][V][modbus_controller:486]: Command sent 4 0x5 1
[16:48:09][D][uart_debug:114]: >>> 02 04 00 05 00 01 21 F8
[16:48:09][D][uart_debug:158]: >>> "\x02\x04\x00\x05\x00\x01!\xF8"
[16:48:09][D][uart_debug:176]: >>> 2 4 0 5 0 1 33 248
[16:48:09][D][uart_debug:196]: >>> 0b00000010 (0x02) 0b00000100 (0x04) 0b00000000 (0x00) 0b00000101 (0x05) 0b00000000 (0x00) 0b00000001 (0x01) 0b00100001 (0x21) 0b11111000 (0xF8)
[16:48:09][W][component:204]: Component uart took a long time for an operation (0.05 s).
[16:48:09][W][component:205]: Components should block for at most 20-30ms.
[16:48:09][V][modbus_controller:036]: Sending next modbus command to device 2 register 0x05 count 1
[16:48:09][VV][uart.arduino_esp32:167]: Flushing...
[16:48:09][V][modbus:199]: Modbus write: 02.04.00.05.00.01.21.F8 (8)
[16:48:09][V][modbus_controller:486]: Command sent 4 0x5 1
[16:48:09][D][uart_debug:114]: >>> 02 04 00 05 00 01 21 F8
[16:48:09][D][uart_debug:158]: >>> "\x02\x04\x00\x05\x00\x01!\xF8"
[16:48:09][D][uart_debug:176]: >>> 2 4 0 5 0 1 33 248
[16:48:09][D][uart_debug:196]: >>> 0b00000010 (0x02) 0b00000100 (0x04) 0b00000000 (0x00) 0b00000101 (0x05) 0b00000000 (0x00) 0b00000001 (0x01) 0b00100001 (0x21) 0b11111000 (0xF8)
[16:48:09][W][component:204]: Component uart took a long time for an operation (0.05 s).
[16:48:09][W][component:205]: Components should block for at most 20-30ms.
[16:48:09][V][modbus_controller:036]: Sending next modbus command to device 2 register 0x05 count 1
[16:48:09][VV][uart.arduino_esp32:167]: Flushing...
[16:48:09][V][modbus:199]: Modbus write: 02.04.00.05.00.01.21.F8 (8)
[16:48:09][V][modbus_controller:486]: Command sent 4 0x5 1
[16:48:09][D][uart_debug:114]: >>> 02 04 00 05 00 01 21 F8
[16:48:09][D][uart_debug:158]: >>> "\x02\x04\x00\x05\x00\x01!\xF8"
[16:48:09][D][uart_debug:176]: >>> 2 4 0 5 0 1 33 248
[16:48:09][D][uart_debug:196]: >>> 0b00000010 (0x02) 0b00000100 (0x04) 0b00000000 (0x00) 0b00000101 (0x05) 0b00000000 (0x00) 0b00000001 (0x01) 0b00100001 (0x21) 0b11111000 (0xF8)
[16:48:09][W][component:204]: Component uart took a long time for an operation (0.05 s).
[16:48:09][W][component:205]: Components should block for at most 20-30ms.
[16:48:09][V][modbus_controller:036]: Sending next modbus command to device 2 register 0x05 count 1
[16:48:09][VV][uart.arduino_esp32:167]: Flushing...
[16:48:09][V][modbus:199]: Modbus write: 02.04.00.05.00.01.21.F8 (8)
[16:48:09][V][modbus_controller:486]: Command sent 4 0x5 1
[16:48:09][D][uart_debug:114]: >>> 02 04 00 05 00 01 21 F8
[16:48:09][D][uart_debug:158]: >>> "\x02\x04\x00\x05\x00\x01!\xF8"
[16:48:09][D][uart_debug:176]: >>> 2 4 0 5 0 1 33 248
[16:48:09][D][uart_debug:196]: >>> 0b00000010 (0x02) 0b00000100 (0x04) 0b00000000 (0x00) 0b00000101 (0x05) 0b00000000 (0x00) 0b00000001 (0x01) 0b00100001 (0x21) 0b11111000 (0xF8)
[16:48:09][W][component:204]: Component uart took a long time for an operation (0.06 s).
[16:48:09][W][component:205]: Components should block for at most 20-30ms.
[16:48:10][V][modbus_controller:036]: Sending next modbus command to device 2 register 0x05 count 1
[16:48:10][VV][uart.arduino_esp32:167]: Flushing...
[16:48:10][V][modbus:199]: Modbus write: 02.04.00.05.00.01.21.F8 (8)
[16:48:10][V][modbus_controller:486]: Command sent 4 0x5 1
[16:48:10][D][uart_debug:114]: >>> 02 04 00 05 00 01 21 F8
[16:48:10][D][uart_debug:158]: >>> "\x02\x04\x00\x05\x00\x01!\xF8"
[16:48:10][D][uart_debug:176]: >>> 2 4 0 5 0 1 33 248
[16:48:10][D][uart_debug:196]: >>> 0b00000010 (0x02) 0b00000100 (0x04) 0b00000000 (0x00) 0b00000101 (0x05) 0b00000000 (0x00) 0b00000001 (0x01) 0b00100001 (0x21) 0b11111000 (0xF8)
[16:48:10][W][component:204]: Component uart took a long time for an operation (0.05 s).
[16:48:10][W][component:205]: Components should block for at most 20-30ms.
[16:48:10][D][modbus_controller:032]: Modbus command to device=2 register=0x05 countdown=0 no response received - removed from send queue
Iām really sorry for such a long absence, but apart from not having had the time to try this myself, I still donāt get any notification whenever someone replies to a thread that Iām subscribed toā¦ I came back here to check just for curiosity.
Itās late now, Iāll read thoroughly tomorrow, but Iām glad that the idea I got to sniff via RS485 has given some results, however primitive that may be as of now. Weāll work on it!
I never done such a thing so I will need some help. As I know this alarm system is using some kind of crypto os. I forgot what it is. I tried to add another keyboard on uniqa but touch screen start flashing so I turned it off. There isnāt any changes in logs.
As I understand Iām just getting info from modbus controller but not from alarm itself.
Ok, I took a look at the whole thing.
With your esp peripheral set as device 2 on the rs485 you seem to only be getting some kind of solicitation or init string from the central component, but obviously there is no interaction, as your esp peripheral doesnāt know what to answer. The thing is, this setup should rather be used to eavesdrop on the dialog between your Unika and the central unit, and furthermore you need to listen to both peripheral 1 (the Unika unit) and the central unit, whatever address it may have. So although Iām no expert either when it comes to rs485, I guess you should try to avoid having to set a specific ID, or maybe use some kind of wildcard value, and then set the circuit/firmware combo to not speak or reply to messages, but listen only, and log the dialog.
How to do that, is another matter, and I need to study and try it myself, because I have no suggestion for you.
In the meantime yesterday I had some time to figure out how to link the spot where my Unika is installed all the way through my desk, as Iām willing to try a slightly different route, i.e. no ESP on the way for now, just my laptop connected via TTL RX/TX pins and serial terminal. So I should be able to start tinkering in a (relatively) short while.
If you come find out something please do post it here.
I have started searching for useful inputs on the net. Came across with a few links Iām in the course of reading. The following seems to be a good starting point (Arduino implementation, can be adapted to esp if you will, but does the exact same thing we are trying to do to sniff the sentences):
http://jheyman.github.io/blog/pages/RS485Sniffer/
Also, if you have a USB-TTL adapter (you said you do) you may want to make your life easier and just follow the same route as Iām willing to do: just link your RS485 dongle via TTL and USB to your computer and start with something easy, for example this software:
I looked it up. Now I tried different things with esp board and I eventually burn it down as I connected 3.3v from the board to the alarm. The problem with esp board is probably voltage I connected rs485 module to the 3.3v pin as 5v pin should go to the alarm. It worked but esp32 board was hot as alarm panel supply 12v.
There is esp32 poe board with ethernet connection. This would suit my needs better as I have poe switch connected to my mesh router node near alarm panel that could power esp32 poe board.
So sadā¦
Iām going to skip the whole esp32 part at first, for the sake of simplicity, and use my laptop instead. You might want to consider doing the same while you wait for the new esp.
No problem. Iām glad I didnāt fry alarm panel or some peripherals. I just canāt connect ttl adapter. I have 17 inch laptop that is big and heavy. My dupont cables are all standard 15 or 20 cm in length. It will be impossible to connect laptop to uniqa, holding laptop in my hand, connect alarm. For me this is not an option. I also canāt connect laptop to alarm panel as it is nearly 4 meters from a ground level.
The only options is to connect something, like esp board, to alarm and try to figure things out from there.
Iām testing right now. I only seem to get garbage on screen, yet it looks somewhat responsive to what I press on the Unika.
Which serial baud rate did you use?
And also, did you cross A and B lines from the Unika to your RS485 transceiver?
I experimented with baud rate 9600, 115200 and maybe some others but I didnāt get any data from alarm panel. A and B lines from sniffer were connected to A and B on alarm panel. I also tried to switch the lines but nothing changed in the logs.
I have the same alarm and the same wishes, I contacted AMC and the told me they are thinking to make an integration but so far nothing. Did somebody made some progress ?
Unfortunately, I didnāt. I also contacted them a few years ago but i didnāt got any replay. How did you contacted them?
I will do the same, maybe it will help.
No progress on my side, either. I still have a valid mitm sniff between my mobile phone and the cloud and an rs485 sniffer setup. What I lack is time to put them to good use.
How did you contact AMC? I will do the same, if it may be useful
I did some basic work to integrate AMC Cloud in read-only mode. If you feel that is something world needs - I can invest more time. Meanwhile, please test.
1 Like
This link returns 404 - page not found.
Indeed. Repo was private by default. Fixed.
I installed it. This is what I get on config
I was able to figure it out using this file.. This should be correct I believe.
But I canāt log in. The error Im getting is āUser login is fine but canāt find AMC Centralā
I dont know why. I populated login screen according to this link.