jec6613

Yes, they all are - i3, s9, and four m6's.

Discovery on initial startup isn't working, and I've tested on both an eisy and a polisy, both with PG3x, seeing the same log entries. Anybody run into anything similar? 2024-02-09 08:24:17,704 Thread-1 udi_interface INFO roomba-poly:start: Roomba node server starting 2024-02-09 08:24:17,772 MQTT udi_interface.interface INFO interface:_connect: MQTT Connected with result code 0 (Success) 2024-02-09 08:24:17,774 MQTT udi_interface.interface INFO interface:_connect: MQTT Subscribing to topic: udi/pg3/ns/clients/00:21:b9:02:60:46_24 - MID: 2 Result: 0 2024-02-09 08:24:17,818 MQTT udi_interface.interface INFO interface:_subscribe: MQTT Subscribed Succesfully for Message ID: 2 - QoS: (0,) 2024-02-09 08:24:17,893 MQTT udi_interface.interface INFO interface:_message: custom data response {'customparamsdoc': '<h3>Roomba robots are auto discovered</h3>\n\n<p>If no robots are configured when starting, the node server will start the discovery process.\nThis will look for Roomba devices on the network. For each device found, you will then have\nto manually put the Roomba in to a mode that allows the node server to query the authentication\ninformation from the device. You will be prompted via a notice when this is required.</p>\n\n<p>The discovered Roomba deivces are then saved so that future starts can skip the discovery process.</p>\n\n<p>If you need to re-discover devices, use the "Discover" button in the UI to start the discovery\nprocess. This will clear any exising devices and start from an empty list.</p>\n'} 2024-02-09 08:24:17,933 MQTT udi_interface.interface INFO interface:_message: Successfully set key = customparamsdoc 2024-02-09 08:24:18,014 Thread-3 udi_interface INFO roomba-poly:handleRobotData: Loading saved robots {'robots': {}} 2024-02-09 08:24:18,018 Thread-3 udi_interface INFO roomba-poly:handleRobotData: We have restored the saved robot list 2024-02-09 08:24:18,021 Thread-3 udi_interface INFO roomba-poly:handleRobotData: Finished with handleRobotData 2024-02-09 08:24:18,054 MQTT udi_interface.interface INFO interface:_message: Profile installation finished 2024-02-09 08:24:18,125 Thread-5 udi_interface INFO roomba-poly:handleConfigDone: No saved robots... 2024-02-09 08:24:18,126 Thread-5 udi_interface INFO roomba-poly:discover: Attempting to discover Roombas 2024-02-09 08:24:18,129 Thread-5 udi_interface INFO roomba-poly:_get_response: Comparing irobotmcs with irobotmcs 2024-02-09 08:24:25,142 Thread-5 udi_interface ERROR roomba-poly:_get_response: Socket timeout while waiting for response 2024-02-09 08:24:26,207 Thread-5 udi_interface INFO roomba-poly:_get_response: Comparing irobotmcs with irobotmcs 2024-02-09 08:24:33,227 Thread-5 udi_interface ERROR roomba-poly:_get_response: Socket timeout while waiting for response 2024-02-09 08:24:34,244 Thread-5 udi_interface INFO roomba-poly:_get_response: Comparing irobotmcs with irobotmcs 2024-02-09 08:24:41,258 Thread-5 udi_interface ERROR roomba-poly:_get_response: Socket timeout while waiting for response 2024-02-09 08:24:42,265 Thread-5 udi_interface INFO roomba-poly:_get_response: Comparing irobotmcs with irobotmcs 2024-02-09 08:24:49,269 Thread-5 udi_interface ERROR roomba-poly:_get_response: Socket timeout while waiting for response 2024-02-09 08:24:50,273 Thread-5 udi_interface INFO roomba-poly:_get_response: Comparing irobotmcs with irobotmcs 2024-02-09 08:24:57,355 Thread-5 udi_interface ERROR roomba-poly:_get_response: Socket timeout while waiting for response 2024-02-09 08:24:58,371 Thread-5 udi_interface ERROR roomba-poly:discover: Failed to discover any Roomba robots 2024-02-09 08:24:58,372 Thread-5 udi_interface.custom INFO custom:_save: Sending data customdata to Polyglot. 2024-02-09 08:24:58,373 Thread-5 udi_interface.custom INFO custom:_save: Sending data notices to Polyglot. 2024-02-09 08:24:58,456 Thread-6 udi_interface INFO roomba-poly:handleRobotData: Loading saved robots {'robots': {}} 2024-02-09 08:24:58,458 Thread-6 udi_interface INFO roomba-poly:handleRobotData: We have restored the saved robot list 2024-02-09 08:24:58,461 MQTT udi_interface.interface INFO interface:_message: Successfully set key = customdata 2024-02-09 08:24:58,461 Thread-6 udi_interface INFO roomba-poly:handleRobotData: Finished with handleRobotData 2024-02-09 08:24:58,541 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2024-02-09 08:25:02,878 Thread-1 udi_interface INFO roomba-poly:addNodes: addNodes: Discovery fround 0 robots!

No, your Eisy came with a thermal pad to use the external case as a heatsink.

So is mine, I used sudo

sudo vm poweroff -f homeassistant And then backup everything in /storage, and you should be able to boot from the NVME and put everything back. Edit: doesn't seem the case, but this is BSD, I'm sure there's a method of doing it, you just may be restricted in storage space for the backup.

I actually already have a headless Celeron based Nuc for that already. It's also a jump box for all sorts of network management, and it is indeed very handy. I'm not sure if a VNC connection would be nearly as effective as RDP though, if I could even get it running on Polisy.

@theitprofessor Just because they have field upgradeable firmware doesn't mean it will be frequent, or that it exists at all right now. in Z-Wave land, a few devices get a few firmware updates, but it's still fairly rare except for right after new chipset releases. Given the new company direction, if there were any updates I think we'd have heard of them by now in their periodic updates - and if they do occur, I hope UD has the time to add in that capability as well. If it does require a hub and it's an important update, I'll probably pick one up, join the devices to it for a firmware update, then just hit restore device in the AC once the firmware update is done.

@theitprofessor I wonder if just doing a device restore would you get to the same place for the dimmer, as IoX would re-write every setting to match what's in the database.

Just what's on the label in the title. I upgraded to an eisy two weeks ago, and am now at the point where holding onto the Polisy as a backup to roll back to no longer makes sense. That being said, it's still a useful little box that sips power, so any creative ideas as to what to do with it? Either with UD's software on it, or somehow stripping the software off, or something else. Just trying to see if there's any options or ideas besides e-waste. The only idea I've had so far is to take the quite attractive aluminum case and use it to make a nifty enclosure of some sort, even if it's just a giant, oversized ZMatter enclosure.

Ditto.

In that case, yeah, I'd use two programs. MS On fires your X10 On, MS Off fires your X10 Off. There are tons of other ways to do it, but I'd keep it simple.

Youi don't need any programs - if the MS is sending both on and off, you just need a scene to handle it.

If you transfer in the portal, that takes care of that part (at least it did for me). I also had my Eisy take over the IP of the Polisy, so I didn't need to change local programming.

I actually have a couple commercially made combiners, I use one to tie in a subwoofer where I only have RCA stereo output, it's quite handy. But yeah, I was just going to remix any MP3's I want into mono if there's no setting. Mine is a Niles system, so similar idea, and I'll probably end up with a Russound system in the next couple of years since the Niles is about 8 years old and discontinued.

Curious, is there the ability to set the audioplayer to Mono mode for output into an existing paging system, even if the source mp3 is stereo? I have other methods to achieve the end result I'd like, Mono audio isn't exactly high tech, but if there happens to be some buried setting, that seems much the simplest.

For what it's worth, I'm going to use this to replace some general paging notifications. Another use would be front door greetings tied in with facial recognition - niche, but cool.

This is exactly what I did the other day, worked flawlessly. If you're using PG3, you'll need to back that up as well, but restoring from backup was butter smooth.

I ended up having my Polisy in service - originally for PG2/PG3 and later as an ISY994 replacement once IoX was a thing - since January of 2020, and just replaced it with the Eisy this morning. Four years of service, and I could have ran it for another year at least before EOL, if not longer, as being x86 and knowing how FreeBSD works it could probably run for much longer, perhaps without new features. That's not bad at all, IMHO.

I do both to be honest. Generally though, a GFCI trip is caused by a faulty GFCI. Newer ones are both more sensitive to actually ground faults, and have fewer nuisance trips. I've only had one go bad, but my brother has had a few dozen. If you're comfortable, usually it's easier to just replace, and if it keeps tripping then call the sparky.

Side note: the Honeywell T6 thermostat also has a power loss alarm, so I use that to detect my HVAC circuit. And I have enough that I can reliably detect a power loss leading to generator start.

Bigger issue for us in the US is they're currently out of stock. Hopefully resolved soon! I've got a few to migrate.

The trouble with HA devices is that, by and large, they remain quiet and dormant except for a once a day heartbeat. You'll need to run a periodic query to see if a device is responding, and then have some error handling, it's not terribly pretty. I solved this with the new Zooz ZAC38. It doesn't solve per se a specific Insteon device offline, but it does have a small battery and fires an alarm when it loses power itself. I spread them around (and replaced a number of much older range extenders) and voila, I have circuit monitoring all over my house.

It definitely doesn't use UPnP at all, because it works and my UPnP is shut off everywhere, so it's using a stateful connection (and I think some DNS-NAT trickery, though I don't know what the web side does).

Pretty much this. Runs great on a server with hard-wired connectivity to the Polisy that never sleeps - otherwise, just close it when done.