u/HangarQueen

I have about 30 old GE/Jasco 300S aka 45606 aka ZW3001 in-wall paddle dimmer switches. They frequently still show "ON" in HA (at some percentage of dim from 25 to 95) when they've been turned off manually.

From some Googling, I found that this is a known problem with these old dimmers: they send an "off" Zwave signal before the dimming is complete, so that the controller sees them as partially dimmed rather than fully OFF.

I also found the circumention: set up an automation to trigger on the switch turning off (or on), then waiting for a few seconds for it to "settle in", and then refreshing the state. I also configured the switch to do its dimming faster (10ms rather than the default of 30ms).

alias: ZWave refresh for old paddle dimmer switches
triggers:
- trigger: state
entity_id:
- light.den_overhead_light
attribute: brightness
conditions: []
actions:
- delay:
hours: 0
minutes: 0
seconds: 3
milliseconds: 0
- action: zwave_js.refresh_value
metadata: {}
data:
entity_id:
- light.den_overhead_light
mode: single

(I created that using the automations UI to test; I'm sure it can be cleaned up a little in the YAML file. )

The automation works. After the 3-second delay, HA now shows the correct OFF state when I turn the switch off manually.

So now I want to do the same for the rest of the 30-ish old paddle dimmers. But I don't want to have to create 30 separate automations! Obviously I can add the other 29 as triggers for this automation. But how can I make the entity_id of the -action match the entity_id of the trigger than caused this automation to run?

Basically I'm looking for a "variable name" for the trigger that I can use in the action so that only that one switch is refreshed. I'm sure there must be a way to do this, right? (I'm very new to HA.)

I set it out to cut my "Back South A" area this morning. This is the ONE area of my yard where it's virtually guaranteed to succeed every time in the past. I can count on one hand the number of times I've had to rescue the robot in this area in the past 2+ years of mowing, and it was always for a dumb thing like a large fallen branch or pinecone.

This morning it's unable to mow more than a few minutes without getting stuck, again and again. It's making lots of full tank turns and lots of tight MPTs that might as well be tank turns for all the wheel-spinning they're doing. With every turn, it digs itself deeper and deeper into the soil -- now that it's completely destroyed the grass layer.

Oh, and one time when it didn't really look stuck, while watching it I pressed "Continue" and sure enough it was able to get out of the rut and back to mowing without problem. It "mowed" two more full rows -- without turning on the blades!

The mower is pretty useless at this point -- except if I wanted some trenching performed around the yard perimeters to install some french drains perhaps. It does a marvelous job at trenching.

Just one example of the perimeter damage it's done to my St Augustine grass. This used to extend to the fenceline and to the forested area with good strong health grass:

https://preview.redd.it/57yt20fg8yjh1.png?width=917&format=png&auto=webp&s=813f099b1c2dc2151f549e0621657d2c483ad70a

Please oh PLEASE bring back full-length MPT as it was late 2024. I went through that whole season with zero grass damage and was singing the praises of Mammotion to everyone who'd listen. I'm sure I personally influenced at least 5 other sales.

And please provide the "skip row" route planning for the Luba 2 (as you've reportedly implemented for the Luba 3). We really need a proper solution to this critical turf damage issue.

And please have your developers do more TESTING on real lawns of various species and grass lengths.

And finally, for the love of &diety, give us a way to ROLL BACK a faulty firmware and app update.

This is my first time visiting this group, though I own pretty much ALL of the M12 Milwaukee tools and am obviously a huge fan. I also own most of the Dewalt 20V tools for larger projects, but I mostly use the smaller/lighter/compact Milwaukee M12s wherever possible. Anyway...

I was out in the yard this morning doing some long-overdue garden weeding and found my Milwaukee M12 driver half buried in the dirt, hidden behind a large leafy plant. OMG, I thought I'd lost it.

Thinking back, and recreating the crime, I remember attaching a post to the house in this area at least two years ago. I also remember (now!) that I'd taken two drivers -- the Milwaukee and a Dewalt -- out to do the work because I wasn't sure if the Milwaukee would have the "oomph" for the large lag bolts. It almost certainly would've had the power, but when I got out there (2+ years ago) I decided to use the Dewalt, setting the Milwaukee down "for a moment" ... and got distracted with something else and completely forgot about it.

It was some weeks later when I realized that it was missing, and after looking everywhere for it, I thought that it was stolen, and fabricated exactly how it had happened in my mind.

It was my most used tool, and my very first Milwaukee M12 purchase easily 10 years earlier. It had been dropped dozens of times onto hard surfaces, run through 1000s of recharges, and always kept working perfectly.

And now it's back again! As soon as I found it, after wiping the dirt off it, I pulled the trigger and was thrilled that it still worked. The battery showed 1 of 5 lights of power still. I took it to my garage, cleaned it up, sprayed it with WD40 liberally, ran it a while, then cleaned it off more.

Two-plus years in the elements, getting rained on perhaps a hundred times. It's looking even more abused now, but still works like new. I just thought I'd post this "attaboy Milwaukee".

I know we're all having issues and this is more "piling on", but just one more...

I was watching the mower cut the front yard this morning. Not TOO terrible. I wish the MPTs were gentler of course (i.e. more forward and reverse length for gentler turning), but it mostly worked this time, and without TOO much turf damage. It got stuck once at a brand new place as it tried a MPT where it wasn't possible to back up, and I had to rescue it. Not the point of this post...

I went back to work around the house while the mower mowed. I saw a notification from the app about an hour ago that it was going back to its dock to recharge. Fine, and I went on about my day.

I just opened the app again to see if it was still charging, but the app wouldn't connect. So I went out to find the robot. Not in the front yard. Not in its dock. Ah!, it dug itself into a hole while rounding a corner of the patio. It's a GENTLE CURVE around that patio corner normally, and it's never had an issue here. Today it apparently decided to tank turn around that corner. Or maybe a MPT that didn't work ... I wasn't watching it. But somehow it dug itself into a hole.

All four wheels were dug in up their axles and the mower was "bottomed out" on its deck. The ground is dry. There WAS grass here but now its dug up. And it had apparently exhausted its battery digging itself deeper, and had shut itself down. I tried turning it on but it immediately turned itself off again.

There was NO NOTIFICATION to the app that it had gotten stuck an hour earlier, nor that it was about to shut itself down. These are very important things to know!

Anyway, I had to pick it up and carry it the 80 feet back to its charging station, place it down and manually back it into the charging pins. It started charging immediately and powered itself back on normally (whew). And only THEN, after it reconnected to the WiFi, did I get a "Robot is trapped" notification. :-/

I'm 70 and have a bad back. The last thing I need is having to carry this heavy robot any distance ... especially in the 90F humid weather of late. :-/ And this was the third time in as many days that I had to do so. I know, first world problems.

I'm grateful that you've re-enabled multi-point turn. But it's not anywhere near as good as it was in late 2024, where it would do nice long gentle turns. And the current app/firmware still does lots and LOTS of tank turns -- that I really REALLY wish you would entirely eliminate.

Given that your lawyers/management are being ultra-cautious with providing full-blown and effective multi-turning, the mower is still doing significant damage to my grass -- and to 90% of your other customers' grasses too, I imagine.

What would help a LOT is if you could teach the mower better zone mapping behaviour to greatly reduce the number of turn-arounds. Here are some relatively simple suggestions that could be implemented:

1. Mow "through" the no-go area perimeter laps whereever possible, so that you can have one long mowing row instead of forcing turn-arounds from both directions. Here's a section of my yard's latest mowing plan as an example:

https://preview.redd.it/kopmwgu4c0jh1.png?width=548&format=png&auto=webp&s=dfccf6ef59c00480f8c762642e7a48976b0d82c9

I've added the red lines (and sorry that they're a little crooked) to show how the mapping COULD just join those row segments while still staying outside of the no-go areas. That is, do NOT segment these rows, but "mow through" the clear path around my no-go zones. In this simple example, there are seven places (red lines) where the mowing rows could be joined -- avoiding 14 grass-destroying turn-arounds. It would also save time, battery, and robot motor wear.

2. Smooth the 2nd, 3rd, 4th perimeter and no-go laps. There's no need to exactly trace the jaggedness of the outermost perimeter lap nor innermost no-go surround lap. These first perimeter and no-go laps are often "jagged" because it's difficult to control the robot in perfectly smooth straight or circular lines while mapping. The susequent laps should be smoothed out. Mow these subequent laps (if any) with a smoothing algorithm used to make all turns as gentle as possible. This would again help with reducing turning damage.

3. Consider providing a map route option where the mower would cut in a continuous loop, skipping over a row or more and looping back to cut the skipped rows a bit later. Here's the pattern for any zone with 3 or more rows. (If just 2 rows, then it still needs to be the usual down row 1, multi-point-turn, and back up row 2.)

Start with row 3. Down row 3, gentle turn along the perimeter, up row 1, gentle turn to go down row 4, then up 2, way over to down 7, up 5, down 8, up 6, then way over to down 11, up 9, down 12, up 10, way over to down 15, up 13, down 16, up 14, and so on and on. The grass "tilt pattern" would be 2 rows up, 2 rows down, 2 rows up, 2 rows down, and so on (so would still look good).

This would almost eliminate the violent 180 degree end-of-rown turns, changing them into gentle curves, while always moving forward, that would be much easier on the grass. And without all that time taken to turn-around, I'm sure the zone would get cut faster and with less battery used. Finally -- and perhaps most importantly at the moment -- it would eliminate almost all of the "dangerous" backing up.

4. Consider adding some handy options when mapping a new area. We need to be able to mark points "A" and "B" on the map and tell the mapping software to "draw a straight line from point A to B". This would be super useful along long fencelines, as it's quite impossible to manually drive the robot in a perfectly straight line when mapping. Having straight properly straight perimiters would again save some turning (however gentle) and grass wear.

5. Similarly, the mapping step should support drawing a circle of a given diameter. Circles are very often needed for no-go areas around tree trunks, and driving the robot in a perfect circle when mapping is next to impossible. So we end up with jagged no-go perimeter laps which cause more grass damage.

I hope you will consider these changes, sooner rather than later! I think they'd go a long way to reducing grass damage and maintaining Mammotion's viability in the robot mower space.

1. Push a software upgrade that disables a key feature used by 90% of your existing customers

2. Provide no way to "roll back" the bad upgrade

3. Respond to all criticism with platitudes and vague promises

4. Provide no timeline or detail for when (if) and how it will be fixed "soon".

I have about 400 cars in my garage. If I want to pick one for a 700PP race, it takes quite a long time to scroll down through them (sorted by PP) to get to the top of that group of cars. Longer of course if I need a 600PP car, and so on.

I feel like there ought to be a "page down" button in addition to the scroll down. Am I missing a quicker way?

<you-can-skip-this-long-intro>
I have an air-conditioned equipment cabinet in my attic to house my modem, router, switch, DVR, power supplies, and some various and sundry other equipment. It's difficult to physically get to, so I have my modem, router, and network switch plugged into an outlet bar that is in turn plugged into a Zigbee outlet that is plugged into my UPS.

(Other equipment, like my CCTV DVR, is plugged into their own dedicated Zigbee outlet so that I can power-recycle them separately.)

I've set up a trivial HA automation to "Recycle modem, router, switch". The automation simply turns off the switch, waits 10 seconds, and turns it back on -- to recycle those components. I can trigger it manually from within HA or by a Z-wave handheld remote talking to HA to trigger the automation.

I used to have the same setup with my Vera Plus controller (with a Z-wave outlet) and it saved my bacon several times. I'd use the remote from downstairs to recycle those network components -- even if WiFi was unavailable. And while traveling and something goes weird with my network -- but with WiFi still available -- I could trigger it manually through the Vera UI (or now, through HA UI).

OK, that was a long introduction; now to get to the point...
</you-can-skip-this-long-intro>

When testing this automation with HA, I find that after the network comes back online, I'm no longer able to reach HA. Not by browser (either by homeassistant.local:8123 or its.static.ip:8123), nor by HA companion on my phone, and not even by SSH. I have to recycle HA in order to regain access.

My HA is running on my QNAP NAS as a VM within Virtualization Station. I can access and login to my NAS and then shutdown and restart the HA VM which brings it back to being accessible. So it's more of an inconvenience than a showstopper. But I'd still like to figure out WHY it becomes inaccessible and fix it if practical.

(By comparison, my old Vera Plus reconnected to the network after recycle and its local and remote interfaces remained accessible.)

Without access to SSH, I'm unable to check the HA logs or ports while it's in this "inaccessible" state. Anyone have any idea of what might be going wrong?

I'm about 1/3rd of the way migrating 200-ish Z-Wave devices from Vera to HA. One at a time, I tediously un-pair from Vera then re-pair with HA's Z-Wave. Many/most of my devices are 10+ years old so it's been an adventure digging up documentation on exclude/include and sometimes factory reset procedures, but I'm fumbling through them.

My latest migration was for an old Zooz 4-in-1 sensor (ZE040). The exclude from Vera was easy, and the include back into HA *should* have been as easy, but... This was the first of my devices that support secure communications. I'm using the default inclusion of "use security if possible" so it was the first time that I was prompted for a PIN to include into HA.

I opened the cover of the 4-in-1 device and immediately saw a tiny QR code sticker attached to the circuit board, so I entered the number from that sticker. The incusion got stuck at "getting device information". I waited a long while but eventually had to X out of it, then remove the "Node 40" that it had created (without proper device config parameters of course). I used the remove form for a working device so that it properly excluded it from HA first.

Then I found another, larger QR code sticker with 5-digit number on the inside of the device's cover. Duh, this is obviously the correct PIN code, so it should be an easy matter to re-add this device afresh.

But upon re-pairing into HA's Z-Wave, it never prompted me again for the new/proper PIN. It just went straight to "getting device information", which hung forever. I tried a factory reset of the 4-in-1 device but got the same problem when re-included. I tried restarting HA and again no help. I restarted the whole virtual server to clean up any cache; same problem.

Evidently, HA's Z-Wave is holding onto the security PIN "somewhere", and it's not deleted when excluding or removing the device from the topology. This makes it impossible to re-include the device afterwards.

Well I don't really care about transport security for this simple 4-in-1 sensor, so after wasting all that time retrying, I did it one more time, but this time opened up the "Security options" area when adding, and clicked on the "Insecure" option ... which allowed the pairing process and getting its device information to proceed normally and quickly.

I'm posting this in case someone else runs into this. And in case an HA developer might see this and know where that PIN is cached (on disk apparently) and be able to fix it so that it's removed when the device is removed.

I've just started the long process of migrating from a 15-year old Vera system of 200+ ZWave devices to Home Assistant. I have HA installed as a virtual server on my QNAP NAS and it's working fine there. I've installed HACS and a few other goodies as I find my way around this new-to-me product, and have moved over many WiFi-connected devices in my network that HA automatically found for me.

The Aeotec Z-stick 10 Pro arrives tomorrow, and then I'll slowly start the exclude-from-Vera and pair-with-HA process in the coming weeks.

A really useful add-on ("plug-in" in the Vera world) that I had on my Vera system was "DeusExMachinaII". It provided a UI where you could configure any number of switches to randomly turn off and on. For each, you could set a range for length of ON time (randomly) and for the start/stop times for when it would (randomly) be in effect.

I had mine configured for a natural pattern from kitchen to living room to den to bathroom and bedroom as the night progressed, with everything turning off sometime between 11 and midnight (randomly) as we "slept". The plug-in would be automatically enabled when the Vera dashboard was put into "Vacation" mode and disabled when set back to "Home".

I can't find anything that provides the same/similar functionality in the Home Assistant world. I'm sure it's "just a simple matter of automation programming" but there are a LOT of details to get right. The Deus Ex Machina ll plugin did this all very well, and I'm hoping not to have to reinvent it.

Update: THANK YOU for the very quick replies below. Yes, the presence simulation seems that it will suffice for my needs. It's not as clever as the Vera plugin's true randomness, but it'll be "good enough" -- and it seems easy to implement. Thanks again.

First of all, I was surprised and disappointed when I picked up my 2026 Sportage PHEV X-Line Prestige (top available trim) to find that it didn't have an auto-dimming mirror. In 2026?! Crazy.

I actually wanted the Homelink function more than the auto-dimming, so I ordered the part from CheapKiaParts.com and installed it today.

Part Number	Part Name	Price	Quantity	Total
DWF62-AU002	Auto-Dimming Mirror W/Homelink	$263.78	1	$263.78

The auto-dimming function works correctly, but only dims the center/bulk of the interior of the mirror. It leaves about a quarter inch of UNdimmed mirror around the entire perimeter of the mirror glass surface.

Can someone who has the auto-dimming mirror please confirm that theirs works the same way? And does it bother you when driving at night to get headlight glare from the perimeter?

At least I can now open my garage door and fence gate with the mirror Homelink buttons rather than needing to carry around those FOBs.

I recently bought (Prime day) and installed the A229 Pro, along with the H6 hardwire kit so I can have parking monitoring.

I upgraded the dashcam to the latest firmware available from the Viofo download area.

I can see on my video timestamps that the Viofo is properly receiving and recording the battery voltage from the H6. (It's also nice but a bit scary that the voltage is also displayed on the Vifo iPhone app without having to connect to any camera first.)

But when I go into the parking mode selection of the app, it doesn't show "Hybrid" as an option. :-(

Am I missing something, or does the A229 Pro not support Hybrid Parking?

And, assuming the answer is "no", then WHY NOT? It would just need another small firmware update, right? I mean it has all the necessary hardware, same as the A329. Maybe they just want to force us to upgrade to get this new useful feature? :-(

It's been very reliable of late, running unattended through several recent mows. Today it cut my Back-South area (about 4000 sq ft), getting 90% through it on the first charge, went back for a recharge, and came out to cut the remaining 10% -- all perfect.

But when it went back to the dock to recharge, I got a "Recharge failed" message on the app, so went to investigate. The light on the dock remains solid green, not blinking as it should if the Luba is charging. The voltage on the pins is the proper 25.3VDC.

I've seen this twice before, and both previous times, it was that the official power supply had gone bad. It would still provide the required voltage when open-circuit, but as soon as the Luba connected to recharge, the power supply couldn't provide the necessary amperage, and the voltage dropped way off.

On both previous occasions, it was still under warranty and Mammotion support shipped me a new power adapter quickly. But while I was waiting for it, I purchased and used an adjustable suppy, adjusted for 25.3VDC of course, and it worked perfectly.

I started off by thoroughly cleaning the contacts on the Luba and the dock, and cleaning the IR lenses of both the Luba and the dock, but it still wouldn't charge. It finds the dock just fine and backs in just fine, nicely centered -- but continues to back up against the dock, "climbing the wall" somewhat. It tries 3 times then gives up.

So then I figured it must be a bad power adapter, again. So I swapped in my adjustable power supply from earlier, verified its 25.3VDC and green light on the dock. I re-checked and re-cleaned the contacts and lenses.

But it still won't charge, and is still climbing up after it's fully backed into the dock. (I think it keeps backing up until it makes contact, compressing the dock pins further to attempt to make better contact.)

I don't have anything else obvious to try. This time it seems that the problem is most likely within the Luba itself. Funny that it happened so suddenly (I mean it had successfully docked and recharged just 10 minutes earlier.) But that's the way electronics goes. :-(

So now, it seems I'll either need to open it up and try figuring out what's wrong, or send it back to Mammotion for repair. But this time, I'm out of warranty (by a month and a half, dammit). I wonder if anyone else has requested Mammotion to repair their out-of-warranty Luba, and how it worked out cost-wise.

Or I could buy another, but of course I just missed the big sale. And I'm not sure I'd buy another Mammotion at this point, frankly. Great hardware but poor firmware (mapping limitations, poor map route planning, far too many tank turns, etc.).

I installed a 2A trickle charger/maintainer next to the 12V AGM battery under the rear cargo floorboard. Easy peasy.

While in there, I noticed that there's also a 12V 19Ah Lithium battery pack. Seems odd that they'd have both a large (H6 size, 68Ah) 12V AGM battery along with a separate 12V 19Ah Lithium battery.

I'm just curious if anyone knows the reason why, and how the 12V loads are divvied up between these two 12V sources.

For reference, here's an example of the Lithium 12V battery for sale on eBay. The one in the Sportage PHEV looks just the same: https://www.ebay.com/itm/306932050398

I bought a '26 Sportage PHEV last month, and the KIA Connect app warns me of a service recall (for a "dark dash" issue) that needs to be addressed by the dealership.

It's great that the app provides a simple way to request a service appointment -- but it's not working for me. :-( I can get all the way through the process to the very end where it has the "Add appointment" button at the bottom (to confirm it) ... but the button does nothing.

Looking up a little on that confirmation page, it has a greyed-out area showing my details (name, phone, email), and in that section, my phone number is showing up in "13051234567" format, with a presumed error message underneath (grayed out) saying "Please enter a valid 10-digit phone number XXX-XXX-XXXX").

I think that may be the reason that "Add appointment" isn't doing anything: it doesn't like the way that my phone number is filled in. But I didn't explicitly fill in that number in that format! It presumably came from my KIA Connect user profile. In my profile, when I enter my phone number as 3051234567, it automatically changes it to "(305) 123-4567" in the profile. And it sends me an SMS to verify it (which I did).

I'm guessing that there's a glitch in the app when it "transfers" my phone number into the service appointment request. There seems to be no way for me to FIX this myself, as the 1305123456 in the service appointment is read-only. I can't change it to the proper format.

Surely I can't be the only one having this issue. Has anyone got a fix or workaround?