I have been having consisten issues with my pro alarm panel. It disappears from the network, can’t update firmware, only two sensors report any zone activity, the log shows really annoying MQQT errors, when I can actually get to the webpage to view it. It’s just very tempremental.
Today I remived the panel from the app and went to readd it by scanning the network. The app wont find the panel. I notice on my router log that the wired connection has a DHCP lease to a MAC of 24d7eba4c9d3 whereas the device listed when it does get discovered is 24d7eba4c9d0 different last character. I have never configured the wifi.
When the app does discover or somehow remember the panel, it never shows an IP being assigned, when it has shown up in the app, but the web page is never accessible. The network name of the device matches the MAC address on the box and in the app, but the MAC address registered in DHCP is different.
I’ve tried flashing the factory firmware, have rebooted a dozen times. It just doesnt work.
Something doesn’t sound right here. First off, are you using our newer firmware platform (made with ESPHome) or the older platform (NodeMCU)? On the newer platform the MAC should stay consistent across the Ethernet and WiFi network adapaters. On the old platform, because both Ethernet and WiFi are enabled at the same time, they have slightly different MAC addresses.
Can you post a screenshot or some logs of the annoying MQTT errors that you’re seeing.
Any details/screenshots you can share would be helpful.
Thanks Nate, here’s a screenshot of my device DHCP lease, you can clearly see that the device name and MAC differ. I don’t know if this is the source of my problem, but I cannot get the device to communicate on the network/ The link light is lit on the ethernet port, but there’s no activity light and the screenshot below shows no Tx data router-side either.
It was working before last weekend when I was trying and failing to get new firmware. I have, apparently, managed to update the firmware twice today, but it’s not made any difference.
The Android App homepage shows ESPHome version 2024.12.4
After composing that message above, I wondered what would happen if I switched to Wifi:
The MAC Address is miraculously correct and I have Tx. I’ll try changing it back to wired now and see what happens, but this is super weird.
Editing this to say that changing back to Ethernet breaks it again, wrong MAC, no Tx.
Hi @John_Quirk – It’s normal to only see one LED on the Ethernet port. On the Alarm Panel Pro v1.8 and v1.9, the green LED indicates a 100Mbps link, and the amber LED indicates a 10Mbps link. Only one or the other should be illuminated at any given time.
When connected to Ethernet, what happens when you open the device’s web page at the IP address shown in your router: http://192.168.50.93. Can you post a screenshot of that page?
I am not sure why the MAC address is showing different. I thought it should be the same. Perhaps your router is doing something odd? I noticed in the first screenshot above it indicates DHCP but the 2nd screenshot on WiFI is indicating a static IP. I will do some experimentation on my end to see if I can reproduce the MAC changing – but regardless it shouldn’t be a problem even if the MAC is different.
I think the static thing is a red herring, the router thinks a few things are static when they’re not.
When I switch to ethernet, I cannot ping or browse the website, it just times out.
Will you post a log for me to review while running on the Ethernet firmware?
Go to install.konnected.io and after clicking Connect choose Logs & Console. Then click Reset Device, this will cause the device to reboot. Let the logs run for 30 seconds or so then click on Download Logs. Upload the file or copy/paste the contents here so I can review.
Odder still, the router entry looks same as always when connected wired, no Tx. But, I can currently access the panel website and see status data being posted and it is responding to ping.
This is now the state that it was in until last Sunday, I believe. I am now going to try installing another firmware config, see if it comes back successfully after that process.
