[APP][Pro] Homewizard 🧙‍♂️

restart of the access point worked. Thanks a lot for your support and have a nice weekend :grinning:

1 Like

Are the new energy sockets working ?

Yes, just make sure you enable local api on all of them.

1 Like

Sorry this is the english section. Please make sure Local API is enabled again in Homewizard Energy app. If that is enabled please reboot your wifi accesspoint that connects your Homey and your watermeter.

Is it possible to connect these with the homewizard app, without any homewizard hubs?

No you need the Homewizard hub. The 868Mhz protocol is protected/locked so there is no alternative sadly.

1 Like

Okay, no problem. At least i know i didn’t something wrong :wink:

Ate those sockets working without a hub ?

Yes those recent sockets Homewizard released last 2 years and the new “slim” model version work without a hub. They all have their own wifi chip.

:+1: thanks

Hi!

I’m sorry, I did something backwards. I sent a diagnostics report with a suggestion for an improvement, 08b9a7af-0a20-402b-825c-240f154ec798.

In short; a device refresh/reconfiguration, when local ip address has changed would be very useful to have. At least for us with a Netgear (and possibly other) routers that cannot clear its arp cache, and release/renew ip address to p1meters that calculated a new anonymized mac address after firmware upgrade, and got a new ip address from router. Even if I change the old reservation, it won’t release and pick that ip, over the new one. So if Homewizard app could refresh its configuration based on mdns data (it remembers the meter id, right?), then I won’t have to re-configure all flow cards manually, and loose all Insight history every now and then…

Hi, this is already covered in my code and here in action for example a watermeter:

2024-06-04T13:54:47.396Z [log] [ManagerDrivers] [Driver:watermeter] [Device:838fe2d1-c6d6-4bf8-b706-510b2929a8c6] URL: http://192.168.2.17:80/api/v1
2024-06-07T08:31:31.362Z [log] [ManagerDrivers] [Driver:watermeter] [Device:838fe2d1-c6d6-4bf8-b706-510b2929a8c6] URL: http://192.168.1.252:80/api/v1
2024-06-07T08:31:31.362Z [log] [ManagerDrivers] [Driver:watermeter] [Device:838fe2d1-c6d6-4bf8-b706-510b2929a8c6] onDiscoveryAddressChanged
2024-06-07T08:31:31.363Z [log] [ManagerDrivers] [Driver:watermeter] [Device:838fe2d1-c6d6-4bf8-b706-510b2929a8c6] URL: http://192.168.1.252:80/api/v1
2024-06-07T16:50:46.201Z [log] [ManagerDrivers] [Driver:watermeter] [Device:838fe2d1-c6d6-4bf8-b706-510b2929a8c6] URL: http://192.168.1.252:80/api/v1

Jeroen,
Thanks. Why do I run into a problem then, when my p1meter is changing mac/ip? Is there something I should do somewhere to make it work?
I am running v3.3.11

Thanks,
Niklas

I really dont know. I dont have netgear myself so can’t relate.
Multicast DNS can be magic but also a pain in the BEEEEEP. As per topic start post I suggest to reserve the address for your P1 to avoid this problem.
What my might help is checking on your end when it changes to compare the output from an mDNS browser app with the before and after and see if it triggers the “onDiscoveryAddressChanged” trigger in my code.

It is just like Zigbee or Z-Wave, every vendor has their own view how it should work but yet are deviating from what it should do to be compatible to all Zigbee or Z-Wave standards.
Same as mDNS, vendors support it but it’s how it is compatible with all to make it work.

Ok, thanks.
I’ll investigate further. Perhaps it’s soon time to retire this Netgear router… maybe Ubiquity will be a better option…

Really try make your P1 have a static ip.

Maybe I was not clear in the previous message.
It usually works, because it got a reserved IP. But I am guessing that at some point, like fw upgrade, it request with a different MAC address. Looks like an anonymized address. And hence my ip reservation is of no use. And together with this, it doesn’t help to change mac in the reservation table and reboot everything. Netgear got some lease cache, that can’t be cleared.

I am yet to dig into the announced mdns packets…

Thank,
Niklas

That is weird, why would Netgear mess up with mac addreses internally. Sure we see it now with Apple and android devices that spoof / use random mac addresses in wifi environment for anti tracking purposes at stores and shopping malls.

Check mDNS for serial record and see if it matches mac address you get in Netgear.

Jeroen,
I believe it’s my p1 meter that spoof its mac address. Perhaps there is something wrong with it. I believe it was the first one sent to Sweden many years ago…

18:16:52.003 p1meter-233514._hwenergy._tcp.local. can be reached at p1meter-233514.local.:80 (interface 6)

serial=3c39e7233514 product_type=HWE-P1 product_name=P1\ Meter path=/api/v1 api_enabled=1

^C

nobook:~ no$ arp -an|grep 192.168.0.10

? (192.168.0.10) at 80:7d:3a:a:3b:29 on en0 ifscope [ethernet]

Original IP reservation was made to 3c39e7233514, but I see one more in the history, plus the current one with the MSB set in the mac address… 80:7d:3a:a:3b:29

Should I perhaps turn to Homewizard support, if this is not expected, in your experience?

Thanks,
Niklas

Hm, does Netgear have Proxy ARP? I know its a feature in Ubiquiti/Unifi where the AP itself is messing with MAC addresses to tackle big broadcast domains and minimize overhead (response time arp). Another one could be guest based wifi ssid’s to restrict AP client interact with each other.

The other mac address from could be the adhoc wifi that is used when initialize/setup the P1 first time.

What firmware is your P1 at the moment?