I only had access to a few for testing so I only listed ones I knew are working.
Here is a link to edit the list
I did not change the line above. Maybe it should say tested / confirmed working systems rather than supported?
Changing it to tested systems makes sense to me. I’m guessing it probably works with any OnCue enabled generator but I was trying to avoid claiming it supported when I can’t test everything.
1 Like
Perfect timing, it works with my 24RCL with RDC2 that was just set up yesterday.
“Please consider making the polling interval shorter, or perhaps user-configurable.”
You can do this via an automation:
- id: generator poll
alias: generator poll
description: ''
trigger:
- platform: time_pattern
minutes: "/1"
action:
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.x9999999_generator_state
Note: The entity_id just needs to be an entity for the device, it repolls the entire device.
Next step: create an automation that polls faster when the generator is running and then goes back to a slow rate when it is not running.
1 Like
“Once the thing seems to go offline, it seems to never come back up until its cold rebooted.”
Did you ever find a solution for this? Mine goes off line for no reason that I see. I have the latest firmware. By the way, reflashing brings it back. I find this easier than a cold reboot.
Bill
I reflash the thing about 3-4 times per year to get it back up. No other solution.
Generator vendor says it’s just flakey and Kohler needs to fix their firmware
Interesting… mine is has been on for 348 days without issues. I was tempted to upgrade the firmware but maybe I am on some island of stability (it says 2.0.5 for what it’s worth).
I am now at 4 reflashes for this year. I spoke to Kohler factory (after a long hold) and they offered no solution. They said either cold boot or reflash to get connection back. Does not seem like an acceptable solution for a company the size of Kohler. As to why @masto has not lost connection I have no idea. I was stable for 7 months and then I lost connection once a month for the last 4 months. No hardware or firmware changes.
I wonder if it’s other traffic on the network. I had an ethernet-connected MIDI controller that would crash randomly, and after digging through massive numbers of packet captures, I was finally able to track it down to it being triggered by certain mDNS broadcasts. (In this case I sent the manufacturer a python script to trigger the crash as well as a video of it happening and they fixed the firmware, yay)
Anyway, part of why I’m guessing this is that I have my generator on an isolated network that can’t see any other traffic. Not that it’s a realistic attack target, but the ethernet cable is accessible outside my house, so I didn’t want it on the same LAN. It’s only talking to Kohler’s server, so there’s very little opportunity for a badly formed packet to set off a firmware bug.
If you have any ideas on what to try and capture ( and how) let me know. I have seen a lot of people with this same issue. Not understanding how a wired device with an assigned IP address can’t reconnect to the router? My router shows it not connected (light out).
It’s suspicious that the link light is going out. Embedded devices like should really be designed with a watchdog timer that hard resets them if they become unresponsive. Kids these days.
It’s pretty hard to give specific advice and instructions, it depends on the hardware you’re using and how much network engineering background you have. It’s also pretty hard to catch something that happens once a quarter. But in general, you’d use something like tcpdump or wireshark with a rolling capture (so you only keep the last X amount of data) and script something to ping the generator in the background and stop the capture when it goes offline. You also have to make sure all the traffic on the generator’s segment is being captured (with a dumb hub or a smart switch/router with a sniffing or port mirror facility). Then you manually inspect everything that happened between the last successful ping and the failure. If you’re lucky, you’ll only have to look at a second’s worth of data and there will be a huge and obvious clue (like in my case, it was a massively oversized mDNS packet).
But Murphy’s law being what it is, you’ll wait 6 months while nothing happens, and then when you look at the data, it will have failed to capture or contain nothing interesting, and so much for that theory.
If I were going to test this theory, it might actually be easier to not try to find the culprit, but see if isolating the generator prevents it from happening again. How to (and whether you can) do that, again, depends a lot on circumstances. I have a mildly capable MikroTik router so I was able to program one of the ports to be on a separate LAN and firewall it off.
I realize this is ultimately not likely to be helpful, and it’s pure speculation that unrelated network traffic is killing it.
Thanks for the detailed response. The above states the issue. Capturing why seems senseless if Kohler is showing no interest in fixing the issue. Devices lose connections all the time, I have had very few devices that didn’t continually try and reconnect after a connection is broken. Nick’s vendor knows of the issue so I am sure that Kohler does as well. They just seem unwilling to try and resolve it.
Is this a hardwired Ethernet to the generator or something else?
Wired connection to router. Static IP address.
That’s interesting. My connection has been stable, though I’ve only had the Ethernet in for a couple of months. I have mine going into an isolated pfsense firewalled subnet. The kohler protocol is certainly chatty sends data every second. To your point maybe it needs to be isolated to be stable.
Folks could try putting in a second router dedicated for the kohler.
I have a stable connection (as stable as possible, with Comcast, and other power issues). I never heard of a dedicated router for one piece of non critical equipment? I would think (hope) there has to be a better solution.
A generator is a critical piece of equipment, at least for me, I want it to run when I lose power. Kohler does not encrypt / securely transmit the data to the cloud, hence I question the overall cyber posture of the device. This thread seems to indicate that mqdns packets can take it offline. There may be packets that could turn it off, our cause it to run. Putting this type of stuff on a dedicated firewalled subnet is a best practice.
To be clear (because I don’t want to have started a rumor), I think all we have is a wild-ass guess and two data points: you and I have isolated subnets and aren’t experiencing crashes. I only brought up mDNS as an example because I had a MIDI device that crashed when it saw large mDNS packets, not because I have any reason to think it’s the same with the Kohler controller.
It would be interesting to see if someone who is experiencing these crashes regularly could try isolating the generator to see if they stop. The more data points like that, the stronger the conjecture that it’s a packet of death. The smoking gun of course would be to capture such a packet and be able to reproduce the failure like I did with the MIDI controller. But that can only be done by someone who is experiencing this, and who knows how and has the equipment to do it. It’s also complicated by being a rare event. In the case of my MIDI controller, it happened within a few minutes of plugging it in. I didn’t have to wait 3 months. A real network security expert could probably “fuzz” the thing.
To @bschatzow’s point, these crashes should not happen, and the manufacturer should fix it. At the same time, they presumably have not gotten a detailed bug report with the exact packet that kills it and a process for reproducing the crash on demand. If someone could hand them that on a silver platter, and it could get to the engineering team, they might be able to do something with it. My experience with the MIDI controller was that when I gave them the data, they responded a few days later with a test firmware to try, and it fixed the problem. I just had a similar experience with Raspberry Pi: I sent in a bug report late last night, and I got up this morning to find they’ve already proposed a fix (which I need to go try now) - Failed boot producing unconfigured netconsole messages · Issue #452 · raspberrypi/rpi-eeprom · GitHub. My fingers are crossed that Kohler would be willing to fix this if they had better information than “it drops off the network every few months”.
The issue of IoT security is real but somewhat orthogonal. Isolating random cloud-connected devices from the network you keep all your important stuff on is probably a good idea. Personally, I do that for some but not all, and the generator was a special case because it’s outside the house. I don’t expect criminal agents to sneak into the back yard, take the cover off, plug into the ethernet cable, and hack my Gibson, but it just felt weird to have it there. Who knows, maybe some service technician plugs it into his virus-infested laptop.
Of course the generator is critical. The cloud app is not.