NOT AN ISSUE: update for wiki

[loph917]

sorry for posting here but wasn't sure how to edit the wiki.

i can confirm that bn-link bnc-60s that i bought from amazon over the black friday holiday would not take a tuya-convert to tasmota. so i stumbled upon your project and after toiling through tuya's process of being a developer etc etc i have them working. you can add to the wiki bn-link bnc-60 (product id rjz4osoyyvsxqtno firmware 1.0.3) as working. same parameters it seems as the existing teckin.

[electronking]

Just went through the whole setup procedure myself with the bn-link bnc-60 4-pack of plugs recently purchased (end of November) from amazon. Got all four plugs [mostly] working with localtuya in HA. Occasionally I'd switch a plug on (or off) in HA and the actual unit wouldn't respond until 10-15 seconds later. Some errors were flagged in the log file. Never got the energy parameters (current, power, or voltage) to update, not even one time. From what I've read, this is a known issue.

The bigger issue in my mind is when I power cycled the plug (ie, unplugged it and plugged it back in). After powering the device back up, HA would no longer see it. The entity state would be listed as "unavailable" and the controls on lovelace are grayed out. The one plug that I have not removed power from continues to work. I did find a recent discussion on reddit about a similar issue here: https://www.reddit.com/r/homeassistant/comments/k3jaqx/localtuya_powercycle/?utm_source=amp&utm_medium=&utm_content=comments_view_all

In my mind, it's a real show stopper if the device looses the ability to reconnect to HA if it looses power. This is likely to happen several times a year during storms and whatnot, not to mention moving devices to different locations would require unplugging them and plugging them back in.

Has anyone else had this experience and if so, know of a workaround?

[loph917]

so i just simulated your issue (kinda). after setting up all four last night i unplugged the all. this morning i plugged in #3 and #4 and both came back online. in the logs i can see localtuya attempting to reconnect all night (which is a good thing!). i have values for volts/amps/watts as well.

i did provide a static dhcp lease for the devices and it's my process to statically IP all of the IoT things around the house. if it's a device and in homeassistant, it's statically IPed via dhcp.

also to note, there are no values for current/current_consumption if nothing is plugged in even if the plug is on. those values don't go non-zero until you have a load.

[electronking]

So the plot thickens... Sometime in the middle of the night I awoke with remembering I restricted each module from internet access in my router by mac address. Time to play...

I started with one device that was "unavailable" (as stated above in my previous message) and allowed it internet access, restarted HA and voila, it started working again. I was even getting the current/current_consumption values. Next I unplugged and replugged in the device and HA saw it again. I then reverted back to blocking that device (from the internet) by mac address and I could turn it on/off at will but the current/current_consumption values only updated one time and and then appeared to be stuck on those values no matter how may times on/off is cycled or it was left on or off for a period of time. While the device was still blocked from internet access, I unplugged it, plugged it back in and remained "unavailable".

So, in a nutshell, I believe this device (bn-link bnc-60) and perhaps others still rely on contacting a server somewhere (not local!) when they start up and when they are acquiring and sending the energy consumption data.

@loph917 If you can understand what I was trying to explain, can you replicate this on your end? BTW, I don't currently have the devices as static but the lease time is long enough that the IP address have not changed... that being said, you bring up a good point, they should be static otherwise you risk your router reassigning them and breaking the link to localtuya. @loph917 Also, how were you able to determine the product id and firmware version of your devices. After a long and painful attempt trying to [unsuccessfully] obtain the localkey though a Development Account (https://github.com/codetheweb/tuyapi/blob/master/docs/SETUP.md) I ended up following a procedure to obtain the key using a rooted version of android in an emulator but I don't know if the product id and firmware version is in the same file where I located the localkey. I looked through it again and didn't find it.

[loph917]

yup i can confirm that on a reboot the device has to reach out to some amazon aws node. how unfortunate. i blocked the plug and tcpdumped the traffic. i could see it sending syns out towards amazon aws. as soon as a disabled the block everything worked just fine.

the on/off functions worked regardless of whether the plug was able to phone home.

as far as product id and firmware i simply used the smartlife app to add the devices and then linked that to my iot developer account in tuya. i wasn't getting caught up in all the drama of trying to make these things work without smartlife. i was able to get the product id from the developer account and all the keys came from the tuya-cli command. in smartlife you can see the firmware version by going to firmware update and see the version.

this entire non-local devices goes against my general principle that any device should be local only. but i paid $18 for 4 and it's not worth sending them back and i can live with these 4 phoning back home to motherland china.

[postlund]

Did you guys consider what is written in this PR?

https://github.com/rospogrigio/localtuya/pull/195/files

[ultratoto14]

@loph917 wiki updated with your device.

[loph917]

@ultratoto14 thanks. might be helpful to put some of the information we've been gathering below (as it relates to the PR metioned previously as well). it seems tuya is making it harder and harder to use these devices independent of cloud connectivity.

@postlund so i attempted what you had pointed out in the PR. i'm blocking the tuya device from egressing to the internet as well from using DNS on my local router (it is the DNS server for the network). the first query that goes it is towards m2.tuyaus.com. there is no response, openwrt is blocking any port 53 requests from the tuya IP.

after a few arp/arp reply packets (normal network stuff) i see the device trying to go straight to an aws host (not sure where it's getting that information from as there's no DNS packets). so device remains firmly unresponsive so either i'm doing it wrong (i am a neteng by trade so i understand all this at a rather fundamental level) or the plugs just need internet access to work.

i verified all this with packet caps on the openwrt device. tcpdump -i br-lan host 192.168.1.231 should capture everything.

happy to try something else or provide more information as required.

[postlund]

@loph917 Can you try to redirect the DNS entries to a bogus host, like 127.0.0.1?

[loph917]

@postlund done. and no change. packet capture clearly indicates the device is getting 127.0.0.1 for it's DNS IP address (which isn't totally intuitive how to do in openwrt at first glance! home gamer tip: tags are your friend).

same results. i can control the plug (on/off) but it doesn't report it's electrical characteristics unless i unblock access to the internet. the moment i disable the firewall rules i get the electrical characteristics for the plug.

it's trying to reach aws addresses still (seems hard to fathom they'd hard code that in firmware). they just don't want us to use their devices without oversight and control.

[electronking]

@loph917 Curious how you are blocking the DNS from the local router. I too am running OpenWrt on my router. Currently I'm blocking the device with the following entries in Firewall Custom Rules: _iptables -A forwarding_rule -i br-lan -p ALL -m mac --mac-source XX:XX:XX:XX:XX:XX -j ACCEPT #BN-Link Module 1

Lastly, drop every packet not coming from one of the MAC address listed above

iptables -A forwardingrule -i br-lan -p ALL -j DROP

Obviously XX.XX.XX.XX.XX.XX is substituted with the actual mac address of the device. Does this seem like a reasonable approach?

Also, I'm not sure how to stop the device from using the DNS server in the router. How are you doing this and how would you go about redirect the DNS entries to a bogus host as @postlund has suggested?

[loph917]

your firewall rules look reasonable. i'm using IPs and not MACs.

per 'tag' DNS assignment (once you do this i believe your GUI might undo these if you use the GUI, not sure about this just something i read somewhere)

dhcp.@host[36].name='tuyaplug-04'
dhcp.@host[36].dns='1'
dhcp.@host[36].ip='192.168.1.231'
dhcp.@host[36].tag='tuya'
dhcp.tuya=tag
dhcp.tuya.dhcp_option='6,127.0.0.1'

[electronking]

Thanks @loph917, I'm still reading through the OpenWrt documentation on the UCI system which is what I believe is what I need to use to enter the DNS assignments you listed above. I'm really a noob when it comes to Linux networking stuff.

So you mentioned that when the device was getting the local loopback 127.0.0.0 for it's DNS address, you were still able to switch it on/off but no electrical characteristics. Were you also still seeing the issue with the device not becoming available in HA when unplugging it and plugging it back in, ie, does it also need to "phone home" on restart?

[loph917]

i was able to plug/unplug with the blocks in place and have control over on/off functions. characteristics weren't read until i allowed internet access.

[alexmorford]

Has anyone had issue with the power monitoring values only updating when the Tuya app is open with the BN Link plugs? It seems to update in near real-time when I have the electric tab of the plug open, but not if it isn't. I haven't blocked them from reading the internet at all.