I have tried an SSD card and a SATA to USB3 connector with my Pi 4B. But it doesn’t work, the Pi 4B does not recognize the SSD and the led on the connector does not light up. I also tried another connector with a power supply, no success neither. Although the SSD is recognized by my laptop (with both connectors) and the connector’s led lights up when connected to the laptop.
Is there something to do with the Pi 4B so that it recognizes the SSD ?
Native USB boot was not available on the Pi4 when it was released. It is supported now but you need to flash a newer boot loader to make it work. You also need to have a compatible USB3 Sata enclosure. There is a list of ones that work online elsewhere and in this forum.
You can test if the bootloader is working by trying the USB2 port. If it boots then the bootloader allows USB boot. If not then it isn’t. If it boots via USB2 but not USB3 then the enclosure is not compatible. My Sabrent enclosure was updatable via windows to make it work.
Anyone having trouble with the new JS device parameter configuration page? according to the update blog “This allows you to manage and adjust device (node) specific configuration parameters for the selected device.” I am not able to change anything. I am on all the latest updates.
Also several devices have blank configuration pages. One device in particular is the fourth device of this particular device. The other three are fine except that parameters can’t be changed.
Thanks for the answer. Indeed I know very very little about Linux, Pi and so on. So I have gone the simplest way, adopting HASSOS and Pi as suggested in the HA installation guide.
Is it possible to flash the Pi boot loader in such configuration ? If yes, do you know where I can find the instructions or utility to do that ?
TIA
There are plenty of guides online on how to do it. You will need a spare SD card but it is not too difficult - copy and paste some commands.
Try this guide - it worked for me…
Thank you 
I only have hs110 outlets. Been pretty stable currently. Had few months back more issue them being unavailable. Now just ease and no interventions needed
Correct. The HS220s are the ones that seem to keep it from coming up unless they are manually defined as dimmers without discovery enabled. The HS1xxs seem to have no issues when I was testing.
1 Like
Need some advice on a template variable that occasional renders with a log warning…
I have an automation that uses MQTT payload_json.
The entity sending the MQTT payload is sending json most of the time (and the template works),
but on occasion it sends a simple one word text message in the payload instead of json and this is causing the log warning to appear.
Here is what I have currently:
condition:
condition: template
value_template: >-
{% set ns = namespace(found = false) %}
{% for foo in trigger.payload_json.predictions %}
{% if foo.label == 'Bus' and foo.confidence >=10 %}
{% set ns.found = true %}
{% endif %}
{% endfor %}
{{ns.found}}
On occasion this generates: 'dict object' has no attribute 'payload_json' when rendering '
Any suggestions? Thanks!
Automation trace - this is great and a much-welcomed feature. Thank you.
Any plans to bring trace debug functionality to scripts? It’d be handy to debug them in the same way!
2 Likes
Based on my experience with this situation, there’s no way to handle it gracefully in a template. The template expects the data to be received in JSON format and that’s how the payload is processed. If the received payload is not in JSON format, the conversion fails and is reported, as an error, before it can be passed to the template (in fact, it aborts and nothing is passed to the template).
My preference would be that it posts a warning message (or not) and passes something that can be tested for validity.
{{ trigger.payload_json if trigger.payload_json != None else 'oops' }}
or
{{ trigger.payload_json if trigger.payload_json is defined else 'oops' }}
I tried creating a dummy json “default”, but it didn’t work:
{% for foo in trigger.payload_json.predictions | default({"predictions":[{"label":"Dummy","confidence":0}]}) %}
Nothing will work because the moment it fails to convert the payload to JSON it reports the error and aborts.
It would have to pass something to the template to reach your default filter but it doesn’t get that far; it aborts on conversion failure.
It is possible to switch the esphome repository to the one previous to this commit 
esphome_version: e0c5b456942a696bb3f9741736a122c0112ea393
Sorry mate i can answer that one. i dont use the addons
I am not sure, but I think this is the commit immediately before
c00c2d43bb7a5c1a0f5f6837e1c084327ff21c72
Any way to make the Automation traces last longer?
I find one of my automations didn’t work properly when I arrive home. Within 3 minutes of getting in the door I open it up, and ‘Chosen trace no longer available’. Can I make these things persist for at least 1/2 hour so I’ve got time to open them up?
https://github.com/esphome/esphome/tree/c00c2d43bb7a5c1a0f5f6837e1c084327ff21c72 doesn’t seem to exist…
But this one does 
(which is not a exactly a link to a commit, but an archive tree link from april 7th )