-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSS310 no sensor readings but switchable #55
Comments
Hello @kr0ner ,
Also, in some other docs I've read that the time setting could be done through MQTT but I've never tried to accomplish this in meross_lan (even tho it should be doable and I'm planning to try implement it) So, in the end, easy fix (maybe): |
Thanks a lot for the input :) I'll give it a try and report back. You should setup a "Buy me a coffee" link in the meantime 😁 |
@krahabb I've checked my router setup and NTP seems to be accessible. No ports are blocked and NTP works fine on my workstation. When using the official app I think I saw something with timestamps and they were correctly set.
|
Ok, played around a bit and I was able to (re?)set the clock of the device via MQTT^^
Not able to test, if I can use this to properly set the time since I am getting a "sign error" when I change the payload 😟
|
Hey @kr0ner , If you want to play a bit with mqtt you could do that from HA 'Developer Tools' -> 'Services': there's a meross_lan.request service which you can use and it will manage the signing/filling of the payload header. This way you can easily test any payload structure and see what's happening. Sure you'll have to monitor the mqtt flow since HA doesn't contextually shows you any reply from the device. It is very strange btw the issue with NTP. I'm pretty sure my mss310 started working correctly right after opening the NTP ports (I've opened UDP dest port 123) but well..maybe there's also a DNS issue or whatever Anyway, in meross_lan there's a section of code which sets the timezone and DST of the meross and it now works just for that. My intention was to use the same piece of code to also set the (actual) timestamp for 'erratics' devices but I've delayed this in order to be able to think and test it thoroughly since I guess it might be subtle when you deal with time. |
Hey @krahabb, service: meross_lan.request
data:
namespace: Appliance.System.Clock
method: PUSH
device_id: 2103098878720390845048e1e960d6bb
payload: '{"clock":{"timestamp":1628250886}}'
The sad part is ... I still get all zeroes 😢
Happy to help 👍 |
Aww.. If you're up to you can find the modified code in #dev a11a948 |
@krahabb holy sh** you are fast <3 |
Hey @kr0ner , Basically, I've just added the new properties to all of meross_lan sensors so they could partecipate in statistics. Also, the energy meter sensor has it's own 'last_reset' setup according to what I've learned from the docs. Thank you again |
Hi @krahabb I have some quick update for you For testing I used two devices with slightly different firmware.
the second one
Some findings:
Looks like the timestamp needs to be very precise, so possible fix could be: { mc.KEY_CLOCK: { mc.KEY_TIMESTAMP: int(self.lastupdate)}} use { mc.KEY_CLOCK: { mc.KEY_TIMESTAMP: int(datetime.datetime.now().timestamp()}} |
Hey @kr0ner, meross_lan should recognize the plug going offline but it's a nightmare: on MQTT I rely on some timeouts not seeing any response after some request but this conflicts with polls (which are repeated until it's offline) so the code will eventually fool itself. I've already fixed/broken this several times :) and actual iteration is broken.... I'm patching this so even on MQTT I can (reliably?) determine device availability just to fix one point. As per the device being configured 'asynchronously' (i.e. not right after its own initial CLOCK-PUSH) I'll check if it works and fix that. If instead the firmware only accept the CLOCK-Config right after the PUSH that could be a dead end: If meross_lan is not available when the plug connects to MQTT we will never be able to configure it (from what I see so far..) As per the precise timing I don't think we can get any further since we still would have the HA-Python-MQTT services in between and we're not able to determine how much time it takes for our payload to reach the plug..so being 'that precise' when sending might be useless..I'll see anyway, my code was using a relatively freshly cached time() reading so to optimize it a bit and it shouldnt be that far from real time() |
Hello kr0ner Thanks! |
Hello @Ostepanov, The mss310 energy reporting is a bit tricky if the plug doesn't have the correct time (from your logs I see they don't) and timezone. The new version of meross_lan I'm about to release is able (or should since it could also depend on device firmware) to configure the device time and in my tests with my plugs works correctly even if the plug cannot synchronize it's time on boot by itself (Meross devices mostly need to complete an NTP query at boot in order to work correctly). In my network setup I allow meross devices to go through my firewall for NTP queries.
With the new version of meross_lan (2.2.0) you'll be able to fix mss310 time setup even without NTP connectivity. |
Quick info about the 'release' (2.2.0): |
Hi @Ostepanov , as @krahabb correctly pointed out, there is some issue with mosquitto addon for home assistant. The PR above is still open and I did not manage to build a docker yet :/ if you are familiar with docker you can open a shell in the existing container, change the files manually and commit the changes to the container. I'm running this setup and it works. |
Will test the recent dev branch tomorrow to see, if it fixes my startup problems 👍 |
Hi @krahabb, I've again had some time to test the latest 2.2.0 release.
|
Hello @kr0ner , |
No need to hurry :) enjoy your vacation 👍 |
Hi This morning I have the following problem. Although all my switches (lights) are working fine all of my switches are blinking fast with red light as if they are not connected! But all of them still available in HA and working fine. My mosquito broker version is 5.1.1. and in the logs I am getting the following errors.
|
I am struggling as well with the same symptoms:
|
aha, that's good news (in a way) not to be alone with this problem, |
the only difference is: my Meross sockets never worked with HA alone yet - I am moving from Meross connected to HA connected (after Meross company started turning off my lights at home and disabling my sockets remotely) |
I am looking for it all day. after so many hours and still don't know what the problem is. at least the switches still working. |
true, but the guys on the other thread say, that socket will self reset and go OFF after some timeout ;-( |
why? Yours are off? Mine are at this stage 16 hours. I hope that I don't have to do all from scratch. |
mine are ON still |
we solved the problem as well - see the other thread here #63 (reply in thread) |
are you using a seperate broker for meross devices other than HA's mosquito? Bytespider helped me before a while to setup HA mosquito broker to accept messages from meross devices too, so I never followed the above procedure to set it up, thus now I don't know how to continue. For the certificates I had installed duckdns addon. |
@userMak I'm using HA Addon's Mosquitto broker 5.1.1. In order to connect Meross devices in 6.0.1, I need to add a HA user for each device, which I hate and use 5.1.1. Also, the certificate created by Duckdns (Let's encrypt) addon will fail to authenticate on older Meross devices, so you will need to create your own certificate and use it. |
@nao-pon Set up the Certificates ##Create the Certificate Authority openssl genrsa -des3 -out ca.key 2048 openssl genrsa -out server.key 2048 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360 |
@userMak I'm not an expert so I don't know the details. However, with the certificate created by the Duckdns add-on, I could not connect with the same error message as you, but by using the certificate created by the procedure myself, I can connected. I think it doesn't matter what machine you make the certificate on, and it doesn't take too long, so it's worth a try. P.S. I thought |
I did EXACTLY the same ;-) next recreation: 2031 ;-) |
I will try them tomorrow when I return home. I hope I don't mess my system more than it is now. After this procedure you had to reconfigure all the switches in HA or it just worked out? |
I was working on certs for the whole day almost and sockets were not connected (blinking) |
Nothing, as even before all was working except all blinked |
Yes, I will do that, but Ideally I would like to avoid it :) ##Create the Certificate Authority
Is there anything else I should consider? |
the complete guide is here: |
I think the problem was that my sockets were in a corner of my appartment with very bad wifi coverage. I moved them closer to the router an everything seems to be working fine again :) |
Hi all, |
Closing this since it appears stale and mostly 'out of band' with original issue. |
Thank you for the great work! 🙂 |
Hello @Write , If you plan to not pair the devices to your own MQTT broker and let them be managed via MQTT by meross_lan, allowing them to correctly reach the NTP server looks like the only solution I know so far. |
As it says in my edit, redirecting/forwarding all outgoing NTP requests to my local ntp server (which is included by default in OPNsense) is enough and seems to work great so I'm happy with that, thanks for your thorough answer ^^ |
Hi, I'm having this issue with my MSS310s. They are switchable but report 0 values for electricity. They have access to NTP and are not blocked in any way, I also see that they report the correct timestamp.
What could be the reason for them not reporting the correct electricity values? |
@czornikk , |
My Timezone was set correctly. Here you have the device trace Thanks so much for taking the time to look into it. I was using the MSS310 connected to the cloud to get correct readings, but really wanted to switch everything to local MQTT. My MSS210 are working flawlessly with a local MQTT, so I'm already really thankful for that, great job and thank you! EDIT: right as I was posting this I wanted to get another device trace where I disconnect the device and reconnected/turn it on and off a couple of times and now I'm getting readings! So you can close this again, sorry for the inconvenience :( |
Version of the custom_component
v2.1.1
Configuration
Mosquitto
Describe the bug
First of all thanks for all the effort you put into this component :)
I have some trouble to get it to work with two MSS310, that work with the official App and are able to read the power consumption. In HomeAssistant I can see the device but the sensor readings are always zero. Surprisingly I can switch it on and off without any problems. Any hint on how to fix this is appreciated. Thanks in advance 👍
Debug log
The output I get running
mosquitto_sub -h <IP> -u <USER> -P <PASSWORD> -v -t '#'
I've noticed that here I get the more values filled in Appliance.System.All than in the trace output.
And here the output from the debug trace
The text was updated successfully, but these errors were encountered: