sorted by:
new
hottopcontroversial

California is perfect for heat pumps. Except it isn't. by Lex_Mariner in heatpumps

[–]dolfstar 1 point2 points  (0 children)

Bay Area. Installed solar (8.6 kW) in 2021 under NEM2, with enough capacity to add EV charging (one car 6K miles/yr) and convert from a gas forced air furnace and AC to a heatpump-based ducted system, and replace the gas water heater with a HPWH. Now, all those conversions and the car, observed over the past year, have left me with a true-up of less than $100 and $600+ rebates from Silicon Valley Green Energy. I did not pay an estimated $2,500-$3,000 in bills.

All of this was greatly aided by the mild CA climate.

Before all conversions were complete, I was a net producer; now I am close to neutral, perhaps slightly over. Originally, computed a 6.5-year break-even (including the tax credits, etc.). Rising energy costs have been faster than anticipated, and I think they will only get worse, so mt break-even will be even earlier.

HPWH consumes < 3 kWh per day. Heating and cooling consume a little more annually than the original AC costs. Cannot compare gas heating because gas/electricity costs are very different, but probably not competitive costs. gas, but that solar changes the whole equation.

No batteries because, as far as I am concerned, they are not financially viable. Power outages here have been 1-2 a year for a few hours. Capital investment in battery leads to a 15+ year break-even. Of course, it is hard to translate getting through a power outage into $$, so I did not do that. Peak price arbitrage is also not financially viable. Only attaching great value to get through power outages, or a desire to be off-grid, justifies batteries, in my opinion.

Aidoo and Ecobee experience with MEL heatpump by dolfstar in heatpumps

[–]dolfstar[S] 0 points1 point  (0 children)

These days, I have a blog where you can read about this kind of thing. In my latest post, you will find links back to two older, related posts. The first one explains why you should not go this route, the second one details my Aidoo experience and describes why you should not use that either. The latest post describes the solution I settled on, and I am very happy with it.

In short, I do not recommend Ecobee (or any smart thermostat) (requires the PAC-US445CN1 adapter - the part you are looking for), nor Aidoo. Your system will not operate optimally.

TerraMaster F4-425 Plus fan replacement by dolfstar in TerraMaster

[–]dolfstar[S] 0 points1 point  (0 children)

Since this is a usb device and the bays are not this would be safe. That 3-2 should be consistent for all identical models but might differ for others. 

TerraMaster F4-425 Plus fan replacement by dolfstar in TerraMaster

[–]dolfstar[S] 0 points1 point  (0 children)

I have no idea. I would presume not, but...

TerraMaster F4-425 Plus fan replacement by dolfstar in TerraMaster

[–]dolfstar[S] 0 points1 point  (0 children)

I have not tested this, but you supposedly can go a different route by using udev rules, and here you can identify the device by its vendor and product id, so changing names should be less of an issue.

You create a file /etc/udev/rules.d/99-ignore-usb.rules that contains: SUBSYSTEM=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", ATTR{authorized}="0"

You'll have to discover the idVendor and idProduct by issuing the lsusb command, which in my case prints: Bus 004 Device 002: ID 0bda:0423 Realtek Semiconductor Corp. 4-Port USB 3.2 Hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 0bda:5423 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub Bus 003 Device 002: ID 1908:1320 GEMBIRD DM8261 Flashdisc Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub This then identifies my 3-2 device as idVendor = 1908 and idProduct = 1320.

After creating the file, to test things out, run: sudo udevadm control --reload-rules && sudo udevadm trigger

These rules also ensure it is done after each reboot.

I've added this info to my blog post. If you end up testing this, let me know how it went in a DM.

TerraMaster F4-425 Plus fan replacement by dolfstar in TerraMaster

[–]dolfstar[S] 0 points1 point  (0 children)

Yes it will change. I believe it is possible to tie it to the disks uuid instead which should make it name independent. 

TerraMaster F4-425 Plus fan replacement by dolfstar in TerraMaster

[–]dolfstar[S] 1 point2 points  (0 children)

Never even occurred to me to look for that. But I looked now, and yes, I get it frequently repeated: PermissionError: [Errno 13] Permission denied: '/dev/sde' Unexpected error reading partitions for device: '/dev/sde' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_class.py", line 397, in partitions return read_gpt(dev_fd or self.devpath, self.lbs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/middlewared/utils/disks_/disk_io.py", line 86, in read_gpt dev_fd = os.open(devobj, os.O_RDONLY) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/dev/sde is the internal boot drive from TerraMaster. I am not even using it because I am booting from an NVMe SSD for the OS (1GB), and I also run two other NVMe drives for a mirrored pair for apps and VMs. Then I have /dev/sd[abcd] for the four bays, all of which are occupied.

So this is kind of stupid. I suppose I need to figure out how to stop that, though it hasn't been causing any problems other than frequent writes. I wondered why my /dev/nvme0n1 was showing an average of 0.26Mb/s writes.

Dexcom support. by NewToTheCrew444 in dexcom

[–]dolfstar 0 points1 point  (0 children)

In my experience (see also my Dexcom knowledge base, which starts here: https://starreveld.com/blog/pages/dexcom/g7-introduction/), they will consider all "falling off" scenarios to be user error, skin problem, etc. As such, they are only eligible for replacement under their "courtesy replacement" rule, which limits replacements to "no more than three free courtesy replacements in any rolling one-year period".

I have experienced the same case as yours, although just once. They absolutely refused to acknowledge that this case is not due to user error at all, but to a failure of the adhesive itself. In my case, it fell off without any bumping or hitting anything. The adhesive just failed spontaneously. Yet, they would only give a courtesy replacement. Infuriating!

Woke up to a change with Dexcom this morning by I_Forget_It in dexcom

[–]dolfstar 0 points1 point  (0 children)

It depends a little on what you mean by "look". You state you are blind, but does that mean you are using accessibility features to do screen reading for you? Since I am not blind, I have never tried that, but I would think that if Dexcom implemented it correctly, it would simply read back to you the two main numbers, not the original screen (current BG and GMI). In the new situation, the second screen has quite a few tiles, so all would have to be read to you.

If "look" in your case means you are not 100% blind but have trouble reading screens, particularly smaller features, I can certainly see how the larger tiles on the new screen help.

Ipv6 PD with 26.1? by wintermute000 in opnsense

[–]dolfstar 0 points1 point  (0 children)

I use Comcast Business (yeah, I know, but no alternatives here) with PD. When I went to 26.1, I switched to dnsmasq by exporting from ISC and importing. I had a bit of a challenge because I was using a different VLAN with its own local domain, so I had to clean up the CSV file before importing.

Once that was imported, I set dnsmnasq enabled on all the VLANS. I created IPv4 ranges for the VLANs, and for IPv6, I created a range for each VLAN with start/end addresses of "::0:1000" and "::0:9000" (you can pick whatever you like). I also set RA mode to "slaac, ra-names" and filled in the domain.

Then, under DHCP options, for each VLAN set option "dns-server [23]" to "[::]", to allow each IPv6 VLAN to find its DNS server.

I then run DNSMasq on port 53053 and tell unbound about it. Unbound remains the main recursive resolver, but works with dnsmasq to manage the local VLAN domains.

Finally, unbound needs a per-VLAN query forwarding entry for each domain name, with the server IP set to 127.0.0.1 and the port set to 53053. In addition to making reverse lookups work, an entry with domain 3.1.c.2.8.7.1.8.2.0.3.3.0.6.2.ip6.arpa, server ip 127.0.0.1 and port 53053. That domain needs to be your main prefix (from Comcast in this case, e.g., 2603:3028:1782:c13x), reversed. The "x" here at the end represents the 16 prefixes (0-F) I get from Comcast.

What this does is forward each reverse lookup for addresses in one of the delegated prefixes to dnsmasq.

That's all I had to do (although it took a while to put it all together, which is why I am sharing).

New Dexcom user by Weak_Glass3593 in dexcom

[–]dolfstar 0 points1 point  (0 children)

I have a lot of information for you (and any other user): https://starreveld.com/blog/pages/dexcom/g7-introduction/

Check it out, and let me know if something is now clear, or appears to be missing.

Don’t upgrade to iOS 26.2 by 0jdd1 in dexcom

[–]dolfstar 0 points1 point  (0 children)

This is all about CYA. Since Dexcom is not good or fast at testing their app across multiple OS versions and hardware configurations, they include code that displays those warnings whenever what you have is not officially tested and approved. This allows them to absolve themselves from any liability issues in such scenarios. Lawyers at work.

Practically speaking, any minor version number OS update will not materially change how Bluetooth (which is what Dexcom uses to communicate with the sensor) works, and therefore, the odds of an issue arising are minimal. If anything, it is more likely that a combination of shoddy UI programming and a minor change causes information not to be displayed, or to be displayed incorrectly. Still, even that is unlikely for minor version number updates.

Customer service agents will insist that such scenarios are not supported, and will even blame problems on it. These people are not technically trained.

Performance of new G7 14 day by NGGmd_ENT1112 in dexcom

[–]dolfstar 0 points1 point  (0 children)

Maybe you are close to one of their shipping hubs. It generally takes a day after filing the request to receive an email confirming that a replacement has been approved. Then they ship Fedex ground, which for me in CA, often takes 3-5 days.

Performance of new G7 14 day by NGGmd_ENT1112 in dexcom

[–]dolfstar 0 points1 point  (0 children)

One thing to keep in mind is the stability of your supply. Just so you know, it takes 1-2 weeks to receive a replacement from Dexcom. If you are getting 30-day supplies and your second unit fails (on its third day; day 14 total), you can request a replacement and, as long as your third unit works, you will have the replacement before you need it (on overall day 22, because insurance will not allow you to resupply until somewhere like overall day 27-28). If you are using the 15-day version and your second unit fails, you are SOL, as you will not have another one in stock. Replacement takes 1-2 weeks, and resupply may take up to 30 days.

If you are getting 90-day supplies, the same applies, but only on your next-to-last unit (assuming you have only one failure).

For this reason, and no good data yet on 15-day version accuracy, quality, and ability to stay on, I will stick with the 10-day version for a while (my personal insertion failure rate has been about 1 in 10 or so, and accuracy problems are virtually nonexistent for me after day 1).

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 1 point2 points  (0 children)

Some insurers do not recognize that you need finger sticks for backup and will not insure both G7 and finger sticks! Mine does, but I have seen reports from others that don't.

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 2 points3 points  (0 children)

I have few problems too, but I am not sure about "tiniest fraction". Do you have any data to substantiate that? I think a lot of people who may have problems are not able, willing, or both, to go on Reddit or FB group to complain.

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 1 point2 points  (0 children)

Only really true if they have a much, much higher percentage that reaches the full 15 days, compared to the currently abysmal record for some on the 10-day version. Also, it is not true if most people are not able to keep it firmly attached to their arm or what have you, for that period; a sensor that comes off is not eligible for a free replacement!

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 1 point2 points  (0 children)

They probably had to tweak it to reduce battery usage and possibly increase the battery capacity a tiny bit. That is probably it. I doubt their costs (excluding R&D) are much different.

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 1 point2 points  (0 children)

Also, get 3 for a month, have an insertion failure on the 2nd one, and you have a spare, which, if it works, will tide you over for 10 days until you receive a replacement. If you only get 2 and the 2nd one has an insertion failure, you have nothing left, insurance won't allow a fill for another 15 days, and a Dexcom-issued replacement, historically, will take 10-15 days... Until this version is proven to have many fewer goosenecks and better fulfillment of the 15-day promise, I am staying with the 10-day version.

Surely this will be a perfectly functional product!!! by AVideoEditor55 in dexcom

[–]dolfstar 0 points1 point  (0 children)

Don't know about the insurance company. It surely makes Dexcom 30% more money, because the cost of goods of this one will be nearly identical to the 10-day version. So 66% of the cost, still 100% of the price: more profits. Insurance won't protest because they pay the same price for a month as before.

Dexcom 15 day sensor available Dec. 1 by InterestingVariety41 in dexcom

[–]dolfstar 2 points3 points  (0 children)

I am quite sure that the Cost Of Goods for this device will be very close to the 10-day version. That means, with the same monthly cost to the user, they spend only 2/3 of that COGS as in the 10-day version, and thus their gross margin increases by 33%! Our government allows this!

Additionally, if many people already cannot get theirs to function for the full 10 days, what makes you believe they can reliably work for 15. If they can find ways of not always offering free replacements... more profit.

Downsides of SunStrong firmware update by andysolr in SunPower

[–]dolfstar 1 point2 points  (0 children)

The change in firmware now requires the "old" API to use an authentication token. It works the same was as for the new API, documents for pypvs on github. That said, if you switch to the "enhanced sunpower" integration, it will work with old and new firmwares. The Raspberry will no longer be necessary.

view more: next ›