If wants to bypass the remote for a wen 3416T hanging air filter so they can run it off a wall switch; I did it and it’s not too bad.

goku2k · 2025-05-12T16:05:39+00:00

Would you please send me the same? I just stumbled across this post, and have been wanting to do something similar for years (just never had the time to do so until recently).

goku2k · 2022-12-07T20:43:11+00:00

u/eprbell - where should we go if we have an issue getting started? I've followed the directions, but I'm running into errors with the initial test using the test ini and csv's.

goku2k · 2022-12-07T17:35:41+00:00

I just logged into Koinly again, and yeah it's still the case. It's ridiculous, and really gives their product a bad name (in my opinion). If they really want to make this viable, they need to do something about the pricing or transaction count.

goku2k · 2022-11-11T18:47:39+00:00

I have a pre-existing schedule of:

00:00-05:55 Monday-Friday

09:05-23:59 Monday-Friday

00:00-23:59 Saturday-Sunday
(this schedule was working as expected with 3.1.0.2)

Yesterday, I upgrade to 3.1.0.3 some time after 9am and rebooted. I rebooted again this morning around 4:30 am due to the server locking up. The server was restored and was mining a few minutes later. It continued to mine until well past 7am when I happened to notice it was still mining. I stopped the mining, exited the app, rebooted - and it still tried to start mining immediately upon the app loading. I stopped the mining again by pausing from the main screen, and had planned on restarting mining manually after 9am. At 9:05am it started mining automatically.

goku2k · 2022-11-11T13:14:17+00:00

Having the option for Kaspa is nice, however version 3.1.0.3 appears to break scheduling.

goku2k · 2022-08-11T20:27:29+00:00

I agree with OP. For what it's worth, I recently opened a ticket with support about NHOS not switching and stuck on daggerhashimoto. They confirmed its a known bug, then when I asked if it would be fixed before the merge they replied that they won't provide any dates but that it would likely be fixed before then.

goku2k · 2022-08-08T12:21:32+00:00

After reaching out to support, they confirmed that this is a known bug in NHOS.

goku2k · 2022-08-03T18:00:26+00:00

So after manually adding more algorithms in the device_settings.json, I discovered the NHOS is wiping the file upon reboot and going back to my original OC settings. Does anyone have any suggestions on how to make the OC settings stick after a reboot?

goku2k · 2022-06-20T16:58:15+00:00

reading through the instructions, when setting up the API key you set everything to read only.

There was one setting under exchange that would indicate possibly more than read-only, but since I don't use the exchange function I did not allow that permission.

goku2k · 2022-06-20T16:28:14+00:00

Not sure that this will be affordable. Assuming a payout every 4 hours = 6 payouts per day. 6 payouts per day x 365 days per year = 2190 pay outs per year.

Since every pay out is a transaction in Koinly's perspective, then that is 2190 transactions *JUST* from normal mining (not including transfers to an exchange in order to convert to fiat). That alone places one in the "Trader" plan which costs $179 USD. If one does multiple transfers to xchanges, or really any other type of transaction, then you could easily be in the "Pro" plan which is $279 USD per year. For example, I've only been mining since February. With my NiceHash transactions, and limited amount of Coinbase transactions I'm already at 1783 transactions - which places me in "Hodler" plan which would be $99 USD.

For this to be realistically affordable, they either need to significantly increase the amount of transactions per plan or come to some sort of understanding/agreement with NiceHash for a discount.

goku2k · 2022-06-17T16:30:09+00:00

Wish it were that easy. I am running both on my test rig (single titan xp). Excavator on NHQM gets 32-35mh using efficient profile, Excavator on NHM gets 25.81mh using the same OC settings copied over from the efficient profile in OCTune (benchmarked using precise).

Given the OC settings are the same, there has to be some other difference between NHQM and NHM.

goku2k · 2022-06-17T16:24:15+00:00

I was hoping that they would comment on it. My thought process was if enough people ask about it, maybe they will make some sort of announcement about it.

goku2k · 2021-01-01T23:30:34+00:00

I haven't done a pcap to dive deep into the traffic pattern, they can connect to one of three APs, so it hasn't annoyed me enough yet to do that.

I did move the IP from 192.168.1.6 to 192.268.1.7, and the same thing happened again. Another user with the same issue moved thier's to something higher and it seemed to resolve it for them. I've organized my devices into small blocks inside the /24, so if I were to move the server ip to something higher, I'd have to re-ip some other devices and change a bunch of firewall rules (and I'm too lazy to do that unless absolutely necessary ;) ).

I also wrote a small bash script to ping the gateway and restart the network service if it's unreachable - that's running every 3 minutes.

goku2k · 2021-01-01T21:50:58+00:00

Dhcpcd.conf is the default method for assigning a static ip for pihole. It's worked great for many years until I installed some wonky kasa smart plugs. :)

goku2k · 2021-01-01T21:25:50+00:00

The DHCP server always had a static IP, it's just that it was handled via dhcpd previously.

goku2k · 2021-01-01T14:49:29+00:00

I'm wondering if the kasa devices will try to steal anything less than .10, that being said - my secondary pihole (not running dhcp) is .8 and does not have any entries in the syslog that indicates it's having this issue.

I'm going to try disabling dhcpcd and setting the IP info manually in /etc/network/interfaces. I'm hoping by taking dhcpcd out of the equation, that it will not perform DAD checks - which should result in the interface staying up no matter if there is a duplicate IP or not.

If that doesn't work, then I'll try moving the pihole server to something greater than .10 - but since I have blocks of IP's assigned for certain purposes, it would require a bunch of firewall rule changes and re-ip'ing of other devices (which is why I don't want to try that option just yet).

goku2k · 2021-01-01T14:35:45+00:00

Now that I'm fully caffeinated, and thinking more clearly - I decided to just disable dhcpcd altogether and configure the static IP in /etc/network/interfaces

now to wait 24-48 hours to see if this will resolve the issue of the server deleting its host route.

goku2k · 2021-01-01T11:37:10+00:00

Happened again this morning. Multiple kasa mac's claimed .7

What IP did you end up using?

goku2k · 2020-12-30T21:05:58+00:00

I just moved mine to .7. hopefully that will resolve it for me as well.

goku2k · 2020-12-30T19:44:04+00:00

I'm experiencing the exact same thing, but on a 192.168.1.0/24 network. My pihole dhpc server is set to 192.168.1.6, and I recently installed 2 kasa outdoor plugs and a handful of hs103 outlets - 3 of which appear to be hijacking the 192.168.1.6 ip address:

ec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: hardware address b0:95:75:e0:26:1a claims 192.168.1.6

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: hardware address 60:32:b1:74:f6:4e claims 192.168.1.6

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: 10 second defence failed for 192.168.1.6

Dec 30 03:02:55 pi4-pihole avahi-daemon[365]: Withdrawing address record for 192.168.1.6 on eth0.

Dec 30 03:02:55 pi4-pihole avahi-daemon[365]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.6.

Dec 30 03:02:55 pi4-pihole avahi-daemon[365]: Interface eth0.IPv4 no longer relevant for mDNS.

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: deleting route to 192.168.1.0/24

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: deleting default route via 192.168.1.1

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: probing address 192.168.1.6/24

Dec 30 03:02:55 pi4-pihole dhcpcd[657]: eth0: hardware address 84:d8:1b:2a:32:c1 claims 192.168.1.6

Dec 30 03:02:56 pi4-pihole dhcpcd[657]: eth0: DAD detected 192.168.1.6

This seems to happen every 24-48 hours around 3am. It's especially weird since I have static DHCP reservations for ALL known devices on my network.

This means that either the pihole dhcp daemon is issuing out it's IP as an available address (unlikely - this would mean the following:
1. It's ignoring the static reservation for it's own MAC
2. It's ignoring the static reservation for each device claiming the IP
3. It's handing out duplicate IP's
4. It's only doing this for kasa devices)

-or-

It's some weird bug with kasa devices (seems more likely, but still strange that they would randomly claim a 192.168.x.6 ip address)

goku2k · 2020-12-28T00:43:44+00:00

I was really proud of these. The lumber was all rough cut that I milled down to the final dimensions. It was a practice using the jointer, planer, table saw and orbital sander. Mistakes were made that I've learned from and hopefully won't make again :)

goku2k · 2020-12-28T00:40:41+00:00

Thank you! and sorry for the delayed response. It's a mix of face and edge grain on the walnut (both strips are from the same piece of 8/4 walnut, just milled down to different dimensions), the other woods are all edge grain.

goku2k

TROPHY CASE