Skip to content
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

Smart feeder pending feed plan #39

Open
jsapede opened this issue Nov 19, 2024 · 20 comments · May be fixed by #40
Open

Smart feeder pending feed plan #39

jsapede opened this issue Nov 19, 2024 · 20 comments · May be fixed by #40

Comments

@jsapede
Copy link

jsapede commented Nov 19, 2024

Hello,

once again thanks for the job on the smart feeder ! manually everything seems to work but i'm stuck with feedplan and scheduler.

i think i made it all well :

made a scheduler with the card :

image

manually feeding works well, but feedplan apear to bes set with "255" int state, i.e. "pending"

image

Timezone is correctly set, i can see the scheduler card update a at good time but, all feedings are skipped

did i made a mistake ?

@cristianchelu
Copy link
Contributor

cristianchelu commented Nov 19, 2024

Hmm... it should have worked.

Did you get to use / pair the device with the official app+firmware before you flashed it?

If your "Timezone Offset" in config is set correctly for your country's UTC offset (+1 I assume?), the only difference I see is that my config oscillates the country code from 1 to 3 instead of 1 to 255.

image

I'm thinking maaaaybe the device will not dispense if it's not "initialized" in the proper region?

I have no idea what numbers are which region but it shouldn't matter as we're no longer in the xiaomi cloud, and mine works with 3... so:

in Developer Tools -> Actions (formerly Services) -> esphome.your_device_name_mcu_command, send the command:

action 9 5 13 3

(Service 9 Action 5 = set-contrycode, with parameter 13 "contrycode" value 3)
image

In the esphome device logs you should receive something like:

[14:40:04][D][miot:150]: Queuing MCU command 'action 9 5 13 3'
[14:40:04][V][miot:096]: Received MCU message 'get_down'
[14:40:04][V][miot:200]: Sending reply 'down action 9 5 13 3' to MCU
[14:40:04][V][miot:096]: Received MCU message 'result  9 5 0'
[14:40:04][V][miot:200]: Sending reply 'ok' to MCU
[14:40:04][V][miot:096]: Received MCU message 'properties_changed 9 13 3'
[14:40:04][V][miot.sensor:011]: MCU reported sensor 9:13 is: 3.000000
[14:40:04][V][sensor:043]: 'Device Country': Received new state 3.000000
[14:40:04][D][sensor:093]: 'Device Country': Sending state 3.00000  with 0 decimals of accuracy
[14:40:04][V][miot:200]: Sending reply 'ok' to MCU

Let me know if this changes anything.

@jsapede
Copy link
Author

jsapede commented Nov 19, 2024

i didnt paired the device before, and my region was set to 255 !
i ran your command and now region is set to 3

image

now with +1 hour it works !!!

thanks again !

@cristianchelu
Copy link
Contributor

Good to hear.

I'll think about a user friendly way to take care of this uninitialized country code automatically and create a PR with a config update that will close this issue (when I have a bit more free time).

BTW, I only assumed UTC+1 offset from the french in the screenshots, it's safe to adjust that to whatever works for you 😄

Enjoy your fully local feeder!

PS: It's actually good fortune that your device wasn't previously setup with the official app, we got to see new behavior and fix stuff, so thanks for that! :)

@jsapede
Copy link
Author

jsapede commented Nov 19, 2024

mill make it in production this weekend to see if everything is ok

@cristianchelu
Copy link
Contributor

@jsapede When you do test, can you also check with device country set to 1? i.e. action 9 5 13 1.

I'm thinking we can avoid the noise in the Logbook of "Changed to 1, changed to 3, changed to 1..." every hour, if the country setting has no effect.

I've had my feeder on this 1 setting for two days now with no bad change in behavior, it keeps working as it should. Hopefully yours will be too.

If this works, I can just add an action in the config "if the country code is 255, set it to 1, otherwise have a nice day" and hopefully future users of this config won't have to notice something ever was not configured.

Thanks in advance!

@jsapede
Copy link
Author

jsapede commented Nov 21, 2024

Will make a test tomorrow

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

it goes stranger
changed region to 1, no schedule working, manual feeding ok
reverted back to 3 and scheduler doesnt seem to work anymore ...

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

maybe something i dont understand well but, here's my plan

image

and see what ischeduled :

image

as we can imagine de feedplan is position/hour/minutes/portions/state

if i write baack the scheduler i got :

0 5:45 4 255
3 17:45 4 255
4 14:45 4 255
5 20;45 4 0
7 11:45 4 255
8: 8:45 4 255

there a 6 possitions but wrongly numbered / ordered it seems

at this time here GMT+1 it's 14:55, how can 17:45 be 255 and 20:45 be 0 ?

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

erased all the schedules, then built them back, in order

image

order looks good,

image

but all states are back to 255

@cristianchelu
Copy link
Contributor

Yes,

  • when you add a new schedule, it's defaulted to 255 - pending;
  • The order of the ID's doesn't matter, the feeder sorts them by hour:minute anyway;
  • Can you check the timezone setting is OK? Sometimes when I flash the device resets it to +8 (China TZ)

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

Screenshot_20241122-153452.png

@cristianchelu
Copy link
Contributor

If you add a new schedule entry for a few minutes from now, let's say 15:40, it should work.

If it doesn't... I think we can move this to Discord (You can find me in the ESPHome server) for a real-time debug or something, I got nothing else to go on.

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

Nothing happened

Screenshot_20241122-154208.png

@cristianchelu
Copy link
Contributor

Alright, let's try the basics:

  • remove all schedules;
  • turn it off and on again;
  • change the tz offset to something else then back again to set it;
  • open the ESPHome device logs;
  • add a single schedule for a few minutes away;
  • look at the logs (/ share them here via a site like pastebin.com) when the entry is due.
    There may be some clues there.

@cristianchelu
Copy link
Contributor

Another thing that might be interesting to know is the MCU firmware. When you first load the logs it dumps the config in a purple font. There should be an entry there for MIOT with MCU version:

[09:52:40][C][miot:119]: MIoT:
[09:52:40][C][miot:123]:   MCU Version: 0015
[09:52:40][C][miot:125]:   Time: AVAILABLE

I know my feeder was on the latest available firmware when I flashed it. If yours is a different version... we might have more work to figure out what's changed.

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

where to find you on discord, i'm on the #general-support ?

erased all the schedules except the first one, cant delete it !

image

there should be something here as if i add one anothern still cant delete the 5:45 !

image

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

[16:01:32][C][miot:132]: MIoT:
[16:01:32][C][miot:136]:   MCU Version: 0015
[16:01:32][C][miot:138]:   Time: AVAILABLE

@cristianchelu
Copy link
Contributor

Oops, that's a bug in the card component, I'll fix it there, sorry about that.
You can just edit the first entry, it will have the same effect.

I have the same username there, you can search for me and shoot me a DM.

@jsapede
Copy link
Author

jsapede commented Nov 22, 2024

Hi
It started to work again, as soon a i moved the first schedule (the one i cant delete) later to the current time

Screenshot_20241122-225746.png

@jsapede
Copy link
Author

jsapede commented Nov 23, 2024

Looks like its dorking now After a cycle complétion of the scheduler.

As we found no others explanations, probably thé peuple facing same problème with scheduler should wait a 24h cycle to get things in order

@cristianchelu cristianchelu linked a pull request Nov 23, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants