I have a Pi 1 with irw and mqtt and would like to move to something more compact.
I picked up a Pico W and would like to use this instead.
Does anyone have a similar setup? This is my first project with the Pico W so I’m not sure how to proceed.
I’ve loaded micropython and have it working with a simple script to flash the LED and connect to wifi so I have the basics and I’m looking for the next steps.
thanks
I have several Pico’s in use, all over MQTT (just one using wifi though, the others all use other data transfer types). They’re great little MCUs. I use the Paho Embedded Platform client for MQTT. It’s physical transfer layer agnostic, so you can use it over pretty much any connection (Ethernet, wifi, 2G/3G/4G/5G, NBIoT, etc). It’s pretty low level though and it’s all C++.
I never used MicroPython, but Google revealed these two promising tutorials:
There’s also this ESPHome thing that seems to be all the rage around here and I think they support the Pico W. It’s not MQTT though, but their own protocol. If you can’t / don’t want to write the firmware yourself, you could look into that.
MQTT is also available in esphome but there might be some valid reasons to choose the native api instead 
Specially the homeassistant.event action or even the homeassistant.tag_scanned action which are directly working with the native api might be handy for remote receiving 
what are the pros and cons of having my setup using micropython vs ESPhome?
I’m new to both worlds so if anyone has already done this using either, a step by step would be appreciated.
thanks
ESPHome is a third party code generator. You don’t actually code anything yourself, you create (or copy’paste) a config file. ESPHome will generate the code for you. Pros: it’s very easy, no coding experience required, quick results with no skills required. Cons: you’re limited to what ESPHome can do. You don’t actually learn anything, because you don’t actually code anything. Your devices are entirely dependent on a third party (though open source) code. If there’s a major breaking change in ESPHome, or if some day it is abandoned for whatever reason, you’re stuck unless you want to maintain ESPHome yourself.
Micropython (or C/C++), you actually program your device yourself. You can still use external libraries (and you most likely will, especially with Micropython), but in the end you’re responsible for the code. Pros: you have full control, you can do anything. You learn how to really design and program embedded devices. Your code is much more independent and immune to third party breaking changes if you version lock your dependencies. Cons: it’s harder and has a steeper learning curve if you’re new to programming.
Which one to choose, it depends on your priorities. Personally, being a software engineer, I like designing my own firmware. I like having full control. I don’t like being completely dependent on a third party code generator / wizard thing. If you have no programing experience, and don’t want to learn it, then ESPHome will give you quick and easy results. If you want to learn, then Micropython is an easy way to start. It can be a deep rabbit hole though. C/C++ is for more professional development and has an extremely steep learning curve if you start from scratch.
You might also want to ask what are the pros and cons having your setup using (self made) Pyhton vs Home Assistant? 
Definitely time to market! 
Specially as you state you have no programming skills taking the road to invent the wheel from scratch will not only take tremendous amounts of time but even chances that you are able to par with the functionalities of Home Assistant are somewhere near 
The same probably is true for your question regarding “micropython vs ESPhome” - while it might be an much easier task to “just” integrate some infrared codes received on a esp pi pico w and forward via mqtt it still will be time consuming and the setup will be not very flexible. Also to keep your code up2date (specially to fix vulnerabilities) will continuously suck time and might make it necessary to implement code changes. 
This idea raised here when cooking your own code: 
is the opposite of good practice AFAIK. While fixing bugs and security vulnerabilities often introduces breaking changes when rolling your own code it should be done - specially for wireless devices which make use of TCP/IP 
Good thing esphome does all this auto magically for us 
Breaking changes are mostly handled gracefully and typically found when actually validating a yaml - often it posts directly a solution for the problem 
Other goodies include the ( setup) native api which makes mqtt mostly obsolete when using esphome together with home assistant. 
It’s perfectly good practice, established procedure and even absolutely required in commercial and industrial software engineering for compliance reasons. Every third party dependency update will be carefully audited for all possible direct and indirect consequences a change would have, both technically and legally for liability reasons. Pros and cons of an update are analyzed and as a result, the version either stays locked, is fully upgraded or is partially upgraded by applying only certain diffs. Blindly bumping dependencies like what seems to be common practice with HA is never done, is considered dangerous and very bad practice.
There’s nothing magical about it. You’re relying on the work of others to do it for you. If they mess up, change their minds or if they lose interest for some reason, you will suffer the consequences. That may be acceptable for some, and unacceptable for others.
So people who use an old arduino framework version to compile binaries because thei code doesn’t compile with a newer version (code changes needed for that) acting with good practice? Even though they might expose their devices and maybe even networks to security risks due to not fixing known vulnerabilities? 
Talking Home Assistant or ESPHome here? 
As both a very popular open source projects the chances are quite low that any of them will vanish soon. The risk for virtually every commercial (closed source) solution to disappear on the other hand is very real
A Name change is typical the worst which is to expect when open source project maintainers “mess up”/“change their minds” or “lose interest” Any one remembering StarOffice/OpenOffice/LibreOffice? Owncloud/Nextcloud…
I give up, this is a waste of time. There’s no reasoning with you on this topic.
Be Agreeable, Even When You Disagree
You may wish to respond to something by disagreeing with it. That’s fine. But, remember to criticize ideas, not people. Please avoid:
- Name-calling.
- Ad hominem attacks.
- Responding to a post’s tone instead of its actual content.
- Knee-jerk contradiction.
Instead, provide reasoned counter-arguments that improve the conversation.