Got it that is what I thought but I wasn't sure and just thought I'd ask. Thank you both for your response.
Posts made by jpilarski
pm2.5 and mqtt incomplete python code
Before I go into describing the bug I ran into I want to make a request that the pm2.5 blocks includes temperature and humidity values from the sensor. Now onto the issue:
I am using uiflow with pm2.5 and mqtt blocks. I start off with some block code for the pm2.5 that is working well but when I try to add the mqtt blocks the generated python code is incomplete and it doesn't include the mqtt python code even when there are mqtt blocks. Sometimes, depending on the sequence of when I add the mqtt blocks it will even remove previously generated python code that was and should still be there. If I then try and go back from the python tab to the blocks tab uiflow will lock up and I then need to reload the m5f file. I can get the code to work by typing it into the python editor but I can't get it working using blocks. Here is the file with the blocks and you can see the incomplete python code it generates. I am using 1.3.4 beta pm25 m5f on github
Here is the working python code that I manually typed into the python editor tab.
from m5stack import * from m5ui import * from uiflow import * import module from m5mqtt import M5mqtt import unit setScreenColor(0x222222) m5mqtt = M5mqtt('xxx, 'io.adafruit.com', 1883, 'xxx', 'xxx', 3000) pm0 = module.get(module.PM25) i = None ioTopics = None xPos = None yPos = None pmText = None pmVal = None xPos = 5 yPos = 16 def upRange(start, stop, step): while start <= stop: yield start start += abs(step) def downRange(start, stop, step): while start >= stop: yield start start -= abs(step) m5mqtt.start() pmText = ['SPM 1.0', 'SPM 2.5', 'SPM 10', 'APM 1.0', 'APM 2.5', 'APM 10', '# > 0.3 um', '# > 0.5 um', '# > 1.0 um', '# > 2.5 um', '# > 5.0 um', '# > 10.0 um'] i_end = float(len(pmText)) for i in (1 <= i_end) and upRange(1, i_end, 1) or downRange(1, i_end, 1): lcd.print(pmText[int(i - 1)], xPos, (yPos * i), 0xffffff) wait_ms(300) #ioTopics = topic_data #i_end2 = float(len(ioTopics)) #for i in (1 <= i_end2) and upRange(1, i_end2, 1) or downRange(1, i_end2, 1): # lcd.print(ioTopics[int(i - 1)], 150, (yPos * i), 0xffffff) while True: pmVal = [pm0.get_pm1_0_factory(), pm0.get_pm2_5_factory(), pm0.get_pm10_factory(), pm0.get_pm1_0_air(), pm0.get_pm2_5_air(), pm0.get_pm10_air(), pm0.get_num_above_0_3(), pm0.get_num_above_0_5(), pm0.get_num_above_1(), pm0.get_num_above_2_5(), pm0.get_num_above_5(), pm0.get_num_above_10()] i_end2 = float(len(pmText)) for i in (1 <= i_end2) and upRange(1, i_end2, 1) or downRange(1, i_end2, 1): lcd.print(pmVal[int(i - 1)], (xPos + 130), (yPos * i), 0xffffff) m5mqtt.publish(str('xxx/feeds/pm2-5.pm-1'),str(pmVal)) m5mqtt.publish(str('xxx/feeds/pm2-5.pm-2-5'),str(pmVal)) m5mqtt.publish(str('xxx/feeds/pm2-5.pm-10'),str(pmVal)) m5mqtt.publish(str('xxx/feeds/pm2-5.pm-2-5'),str(pmVal)) #pm2-5.particles-0-3 wait_ms(200)
uiflow firmware issues with stickC
I am trying to install stickC 1.2.3 uiflow firmware on stickC and I get the following error -
A fatal error occurred: Timed out waiting for packet header
I can upload code to this stickC board using arduino just fine. I also tried the 1.3.0 firmware but I get the same error. Also is the 1.3.0 beta only for m5stack.
RE: [Solved]Where to get basic (offline?) MicroPython firmware with lcd module support?
I did come across this info about on screen repl https://forum.micropython.org/viewtopic.php?t=5589
i2c = machine.I2C(scl=machine.Pin(4), sda=machine.Pin(5)) oled = ssd1306.SSD1306_I2C(128, 64, i2c) from FBConsole import FBConsole console = FBConsole(oled) os.dupterm(console)
RE: [Solved]Trouble burning MicroPython firmware
If you install uiflow firmware you have also installed micropython. You can connect to a repl shell, load libraries, and modify main.py. You can use any micropython ide and you aren't required to use uiflow. It is a good option though. I like using upycraft. Even if I am running uiflow I'll still keep a connection to the board open with upycraft to get immediate feedback. With upycraft you have direct access to the filesystem and you can drag and drop files to and from the board. You can also run
where module is one of the listed modules. To learn more of all the built in functions available.
RE: [Solved]M5fire read microphone
@watson @world101 @ajb2k3 @hetzer
I would still consider adding it. I understand it only exists in m5go and fire but then under hardware blocks call the block m5go mic. I just think new users would experiment more with that function exposed as a block. I totally understand I can now make a custom block for this but I still think it makes sense to see it as a default block. It should definitely be exposed for StickC since with that board there is no confusion as they all have a mic. What about having a toggle when the user selects core that designates fire, go, grey, etc. (just like you do with stick and stickC) and have that toggle load the appropriate on board hardware blocks. What about a block that exposes the hall effects sensor too while you are at it. I guess I feel like expose it all since it encourages development and you never know what someone makes with it. At the very least it helps encourage learning and ease of use which seems like the point of block based visual coding.
RE: [Solved]M5fire read microphone
@world101 It is just an adc call with a buffer but it's documented as part of the api. Still wondering why there isn't a block.
RE: [Updated] 20-04-2019 UIFlow big update.
Very informative and super helpful to have all of the specifications and sample files in one document. This is really taking shape.
I have a few suggestions:
---On the hardware side you are getting really indepth and this is helpful to those who may already have some arduino experience but are now interested to try uiflow. However the code examples you are using for the units are more for beginners and I think starting off the book with some very basic code concepts like setup, loops, delay, etc would really help support those samples. At the same time you also might want to have some examples of more complex code to show those experienced users just how capable uiflow can be.
--- I really like that you describe i2c, digital, analog, and uart units. I think it would be great to have an visual index of all units and divide it up, like the periodic table, according to those categories and then have a chapter on each of the 4 types.
-- Start off the unit chapter by showing how a unit is selected and loaded into uiflow and how it adds new blocks according to the selection. This goes over the general workflow of using a unit. I think this can help prevent you from having to explain how to load each specifc unit and focus in on what the unit does.