Martvvliet / homebridge-mi-flora-filtered

MIT License
8 stars 4 forks source link

Log entries in Homebridge show correct data. Defined Accessories do not #5

Open LostJen opened 4 years ago

LostJen commented 4 years ago

I have six sensors currently in use. For ease of use I'm not going to refer to them by MAC but rather 1-6. 5 is at the edge of the range. Visually reading the log or even using grep would show that it was lowish on water. WatchFlower (another open source app to read MiFlora devices) agrees with the logged values. However the Accessory does NOT agree and actually I've seen it's moisture value get propagated into multiple accessories before being overwritten by the next set of values. Further it's low water opened this morning as it should since I just set it up yesterday. Interestingly the value for humidity was like 48% when contact open was 25%. I just watered and it hasn't closed but that sensor can take a hour because of range. In short it looks like the correct values come in, but homebridge-mi-flora-filtered is assigned them to the wrong and/or multiple accessories. Most of my MAC address do start with the same 6 hex chars, but the last two are unique. I am using a Pi 4 and I know you've said you are using a Pi 3, but really shouldn't matter.

Martvvliet commented 4 years ago

Well sadly enough, I only ported this plugin to support node 10+ so not sure why you have this issue. I think it might be due to a static UUID. When I tried to solve this, it didn't work anymore. So I will come back to you about this issue. Thank you for posting :)

LostJen commented 4 years ago

Maybe pull request #9 will help?

Martvvliet commented 4 years ago

Pushed the request to npm. Please let me know if it is working now. I have only one sensor, so can't test this for you. Thank you @LostJen

LostJen commented 4 years ago

I only get power updates now. I suspect someone had a problem in the far past and did a quick workaround (same data across the board is better than none I guess)...... I'm swamped in a huge mess of other projects right now and can't really look anymore. I may just go back to using the open sourced app (to avoid the chinese server hits).

Martvvliet commented 4 years ago

@LostJen Yeah it looks like it indeed. Will also take a look at it when I have the time. For now, I rolled back the update.

Tomobikimn commented 4 years ago

I have the same issue with the values being repeated on different devices. The data in the log is different for each device. I added the Humidity alert for my 3 devices. The Battery, Lux and Humidity alert are correct on all the devices. The Temperature and Humidity % are repeated. The homebridge-mi-flora-filtered was installed on a new Homebridge port on a raspberry pi 4 on the 3rd of Sept

ne0nex commented 3 years ago

Fixed this in my environment.

Pull request #9 was on the right track, but after making the change, it turns out that the comparison is bound to fail because data.deviceId and that.deviceId will never match. The variable 'that.deviceId' is pulled from the config file which if the user is following the guidance from the documentation will be entered in format: "AA:BB:CC:DD:EE:FF" in debugging the 'data' structure, I found that data.deviceId is in format: "aabbccddeeff" which the string comparison will always fail to match.

I added a line between line 59 and 60 (right before the if statement) that modifies data.deviceId to uppercase and used some regex into hack it to the correct format for the comparison to succeed: variablenamegoeshere = variablenamegoeshere.toUpperCase().replace(/..\B/g, '$&:');

Replicate between line 106 and 107 to get it fixed for firmware and battery level, and don't forget to turn = back to == as was done in pull #9.

I'd push this myself to the repo, but alas, my job doesn't permit me to push functional code up to open source projects on personal time without crazy approvals and obtaining clearances. The variablename I modified in my environment was data.deviceId