Any chance you have a power problem? Do you see the same behavior plugged into a phone charger, or using the AC PSU?
Could be. I have it plugged in with a 2A USB Power Supply. The AC PSU is 3A right? Iâll see if I can come up with something to provide more power.
2A should do it, but still canât hurt to confirm supply and cable. What version of the HASP firmware are you running? If itâs a dev build, did it work before with the current master release?
Hi Im setting up from scratch a new HA, hacs HA Switchplate and BwAlarm.
I have most things working except I cannot arm or disarm from my HA switch plate.
Below is my bwalarm.yaml file. Not sure if mqtt commands are correct. When using the lovelace control it updates the HA Switchplate display.
platform: bwalarm
panel:
cameras: []
panel_title: Alarm
enable_sensors_panel: 'True'
hide_sidebar: 'false'
camera_update_interval: ''
enable_custom_panel: false
hide_passcode: 'True'
round_buttons: false
shadow_effect: false
enable_serif_font: false
enable_night_mode: false
states:
armed_away:
immediate:
- binary_sensor.spare_office
delayed:
- binary_sensor.entry
override: []
pending_time: '5'
warning_time: 30
trigger_time: 180
armed_home:
immediate:
- binary_sensor.spare_office
delayed:
- binary_sensor.entry
override: []
pending_time: 60
warning_time: 25
trigger_time: 180
users:
- id: 39642758223b4835abc3063cb47877b1
name: Test
enabled: true
code: '1111'
picture: ha.png
admin_password: a
mqtt:
enable_mqtt: true
command_topic: home/alarm/set
payload_arm_night: ARM_NIGHT
qos: '0'
payload_arm_home: ARM_HOME
override_code: false
payload_disarm: DISARM
state_topic: home/alarm
payload_arm_away: ARM_AWAY
pending_on_warning: false
passcode_attempts: '20'
passcode_attempts_timeout: '60'
enable_persistence: true
code: '1234'
ignore_open_sensors: true
themes:
- name: Theme
warning_color: '#FFFFFF'
pending_color: '#FFFFFF'
active: true
code_to_arm: true
log_size: '30'
It worked pretty well when I installed the dev build on Feb 5th. I am currently running your latest dev. build. I have switched back to the master build a few times, and it connects fine with that firmware. When I get a chance I will try to go back a few versions to see which one starts to break things.
Can you dump a debug log of the connect/disconnect activity somewhere I can look at?
try this:
it is a copy of the serial log
What appears to be happening is that youâre dropping the MQTT connection and itâs then reconnecting. The WiFi connection appears to be left intact, itâs just MQTT. Left to be understood is whyâŠ
I have been messing around with it. For some reason it is working a lot better. I cannot even recreate the issues I was having. MQTT responses are a little slow, but I am not longer getting the connection issues. A few things I changed:
- I have it plugged into a 2.1A power supply (earlier I was using USB so I could get the debug log)
- I enabled telnet, and logged in that way
- I disabled mDNS
- I disabled the sleep automation/blueprint, it was set to 120 seconds, I donât think my screen ever went to sleep.
I also reconnected my other HASP to the same network, in the beginning I really was trying to verify that I wasnât losing connections to my MQTT server, but that one (no dev build, no blueprints, âold fashionedâ hasp) is working flawlessly. I only mention it in case having 2 on the same network helps the MQTT connection somehow.
Still clueless on what was causing the issue.
This is a known issue with how the blueprints work today, and is the reason I havenât pushed this to release yet. This PR should be in the 2021.03 release and I expect it will have a major impact on automation execution time. Right now, nearly all of the HASP blueprints are hoovering up a crapload of MQTT traffic and then excluding the bulk of it after execution begins. Your logbook is probably a mess (I know mine is). Weâll be able to cut that down substantially with better control over which MQTT messages we trigger on and then process.
I should have a more concrete handle on that when the 2021.03 beta cycle starts.
On the one hand yay on the other hand ugh⊠Still want to know why.
Did you get this sorted out? Are you running the production HASP with deployhasp.sh or are you testing the alarm blueprint?
Hi Luma, the alarm blueprint. When I arm or disarm in lovelace it updates the screen just not from the screen to the alarm.
this is what I see in the logs when trying to arm
2021-02-19 03:12:45 WARNING (MainThread) [custom_components.alarmo.alarm_control_panel] Wrong code provided.
Found the issue⊠plate01 was hardcoded into the blueprint. I have submitted a change
1 Like
LOL welp, this is why we beta test I guess. Thanks for the save my friend 
No problem. Your blueprints are amazing!!
Nobody was asking for it but this one has been bugging me for a while. I wanted some visual indicator when a firmware update was happening so one could confirm that itâs actually happening. So now, page 0 also has a progress bar object (not global, and thus doesnât cost me global memory) which can be used to show progress for things like the firmware update. It now looks like this:
8 Likes
I like it! Thanks
WARNING: RANT AHEAD - I need to let off some steam. Let me start by saying I appreciate all the hard work luma has put into this and I really believe in the project and want to see it work. Please forgive me, but I am getting really frustrated with it.
I am starting to get really pissed off at this whole thing. I get it working only to come back later to have it not working and nothing to help debug it. I have been trying to get a 4.3" display working and it is fighting me every step of the way. I got the Nextion file converted for the display and have had it working fine. But then something, I have no idea what, causes the system to not connect to the network or connects, but canât get to the MQTT server. When it canât connect and goes into AP mode, I sometimes can connect to it and attempt to configure it, but the page doesnât always respond. I have wasted so much time trying to just get this stable enough to do something with. 
END RANT
So I flashed the firmware, again, and was able to configure it through the AP. But it wonât connect to the MQTT server. It keeps reporting a rc=0, but from what I see, that is suppose to mean it connected.
[+108.677s] SPIFFS: Configuration changed, flagging for save
[+108.685s] HMI OUT: 'p[0].b[1].txt="Saving\rconfig"'
[+108.690s] SPIFFS: Saving config
[+108.694s] SPIFFS: mqttServer = 192.168.1.200
[+108.698s] SPIFFS: mqttPort = 1883
[+108.702s] SPIFFS: mqttUser = mqtt
[+108.705s] SPIFFS: mqttPassword = xxxxxx
[+108.709s] SPIFFS: haspNâde = devplate
[+108.713s] SPIFFS: groupName = plates
[+108.716s] SPIFFS: configUser = admin
[+108.720s] SPIFFS: configPassword =
[+108.724s] SPIFFS: motionPinConfig = 0
[+108.728s] SPIFFS: debugSerialEnabled = 1
[+108.732s] SPIFFS: debugTelnetEnabled = 0
[+108.736s] SPIFFS: mdnsEnabled = 1
[+108.739s] SPIFFS: beepEnabled = 0
[+108.782s] HMI OUT: 'p[0].b[1].font=6'
[+108.786s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\rë Oxford\rIP: 192.168.1.83"'
[+108.794s] WIFI: Connected successfully and assigned IP: 192.168.1.83
[+108.802s] HTTP: Server started @ http://192.168.1.83
[+108.810s] ESP OTA: Over the Air firmware update ready
[+108.816s] HMI OUT: page 0
[+108.819s] HMI OUT: 'p[0].b[1].font=6'
[+108.823s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connecting:\rïł 192.168.1.200"'
[+108.834s] MQTT: Attempting connection to broker 192.168.1.200 as clientID devplate-bcddc2b62617
[+113.932s] MQTT connection attempt 1 failed with rc 0. Trying again in 30 seconds.
[+113.941s] HMI OUT: 'p[0].b[1].txt="WiFi Connected:\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connect to:\rïł 192.168.1.200\rFAILED rc=0\r\rRetry in 30 sec"'
[+114.008s] HMI IN: 0xff 0x0 0x0 0x0 0xff 0xff 0xff
[+114.054s] HMI IN: 0x88 0xff 0xff 0xff
[+114.741s] HMI IN: 0x63 0x6f 0x6d 0x6f 0x6b 0x20 0x31 0x2c 0x36 0x37 0x2d 0x30 0x2c 0x4e 0x58 0x34 0x38 0x32 0x37 0x54 0x30 0x34 0x33 0x5f 0x30 0x31 0x31 0x52 0x2c 0x31 0x35 0x31 0x2c 0x36 0x31 0x34 0x38 0x38 0x2c 0x45 0x34 0x36 0x30 0x34 0x43 0x44 0x34 0x32 0x37 0x32 0x31 0x31 0x46 0x32 0x39 0x2c 0x31 0x36 0x37 0x37 0x37 0x32 0x31 0x36 0xff 0xff 0xff
[+114.793s] HMI IN: nextionModel: NX4827T043_011R
[+114.849s] HMI IN: 0x66 0x0 0xff 0xff 0xff
[+114.853s] HMI INz [sendme Page] '0'
[+114.897s] HMI IN: 0x1a 0xff 0xff 0xff
[+114.952s] HMI IN: 0x66 0x0 0xff 0xff 0xff
[+114.956s] HMI IN: [sendme Page] '0'
[+115.010s] HMI IN: 0x66 0x0 0xff 0xff 0xff
[+115.014s] HMI IN: [sendme Page] '0'
[+143.959s] HMI OUT: page 0
[+143.962s] HMI OUT: 'p[0].b[1].font=6'
[+143.967s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connecting:\rïł 192.168.1.200"'
[+143.978s] MQTT: Attempting connection to broker 192.168.1.200 as clientID devplate-bcddc2b62617
[+149.080s] MQTT connection attempt 2 failed with rc 0. Trying again in 30 seconds.
[+149.089s] HMI OUT: 'p[0].b[1].txt="WiFi Connected:\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connect to:\rïł 192.168.1.200\rFAILED rc=0\r\rRetry in 30 sec"'
[+149.147s] HMI IN: 0x66 0x0 0xff 0xff 0xff
[+149.151s] HMI IN: [sendme Page] '0'
[+179.108s] HMI OUT: page 0
[+179.111s] HMI OUT: 'p[0].b[1].font=6'
[+179.115s] HMI OUT: 'p[0].b[1].txt="WiFi Connected!\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connecting:\rïł 192.168.1.200"'
[+179.126s] MQTT: Attempting connection to broker 192.168.1.200 as clientID devplate-bcddc2b62617
[+184.229s] MQTT connection attempt 3 failed with rc 0. Trying again in 30 seconds.
[+184.238s] HMI OUT: 'p[0].b[1].txt="WiFi Connected:\rĂ« Oxford\rIP: 192.168.1.83\r\rMQTT Connect to:\rïł 192.168.1.200\rFAILED rc=0\r\rRetry in 30 sec"'
[+184.295s] HMI IN: 0x66 0x0 0xff 0xff 0xff
[+184.300s] HMI IN: [sendme Page] '0'